After a long break I tried a current qemu git/master today. What can I say? The SPARC-related stuff is broken in a few places since a few months. SCSI signals an error for the "Inquiry" command, Leon3 test hangs, sparc64 is broken too. Bisecting is tricky though, because at least sparc64 seems to broken in different ways in subsequent commits.
Don't have time to fix it myself, but will send a couple of bug reports to the mailing list. Meanwhile, what is your favorite qemu version?
Update: meanwhile (7/Feb/2012) SCSI and Leon3 issues are fixed, thanks to Thomas Higdon and Fabien Chouteau.
Don't have time to fix it myself, but will send a couple of bug reports to the mailing list. Meanwhile, what is your favorite qemu version?
Update: meanwhile (7/Feb/2012) SCSI and Leon3 issues are fixed, thanks to Thomas Higdon and Fabien Chouteau.
9 comments:
I'd have to say 0.90 was a favoite as it could run Nextstep... lol
that being said, 1.0 feels like a giant step backwards, plenty of things don't work on windows... I think its glib but I haven't bothered to try to debug it...
and for some reason the default disk access methods are SLOW ...
And I recall the MIPS being kind of weird in 1.0 crashing way too easily as well...
My favorite is 0.11.1. It is the last one which could run HelenOS/ppc32.
Jakub, have you reported this to the qemu-devel@? I think Andreas Färber really cares about ppc-prep. It might be a good test case for him. At least HelenOS used to be a good test case for sparc64.
To boot HelenOS under 0.11.1, do you use OpenBIOS or OpenHackware?
I reported this once, but no one gave a damn about it.
It's OpenBIOS v1.0 built on July 5, 2009.
We are tracking this using HelenOS ticket #407:
http://trac.helenos.org/ticket/407
Note that it's not clear whether this is a HelenOS, Qemu or OpenBIOS bug. It is possible to use this older version of OpenBIOS with some newer versions of Qemu. Unfortunately, 0.12.* has some other problems with loading HelenOS. The newer versions can boot HelenOS with an old OpenBIOS but crash shortly after boot.
I had reported a couple of months ago that I had had some success with Solaris 8. Unfortunately, I spoke too soon. My success had been with Qemu during the April-May 2011 time frame. When I started to try to work with Qemu again in January, I found Qemu much less usable. I went back and tried various old combinations of Qemu and Bios's to see if I could replicate my earlier success. Here are notes about my attempts to run the VM booting Solaris 8 from qcow2 disk image. If it is of any interest.
0.9.1 - Would not compile (under Ubuntu)
0.10.6 - Would not boot (could not find boot program)
0.11.1 - Would not boot (could not find boot program)
0.12.5 - Would not boot (spurious interrupt at process level 10 ... repeating ad infinitum)
0.13.0 - Boots Ok. But hangs during init processing after enabling networks.
0.14.[01] - Boots Ok. Oracle 7.3.1 dies with ORA-00600.
0.15.[01] - Fails during initialization of Solaris with a Qemu segmentation fault.
1.0.[01] - Boots Ok. Oracle crashes. Syslog only works sporadically.
So, you are running Oracle under emulated Solaris? This is interesting. Out of curiosity, why not just take the Linux version?
The pre-0.13 results are not really surprising, these versions lack my patches. The 0.15 must be the consequence of the new shiny memory-api...
But 1.[01] regression is unexpected. Gonna take a look into it, but not very soon. Right now I'm playing with the SPARC bleeding edge - the sun4v emulation.
P.S. Has your company changed its mind about using emulation, is qemu your hobby now, or are you not the bearcat I think you are?
Same bearcat.
No, sorry they've not changed their mind about how to address the obsolescence issue with the product.
Yes, just a hobby.
The workstation used with the product in question is part of a medical device. It requires a lot of paperwork, cost, time, to get approval from the multitude of country regulatory agencies around the world to sell the device. As such we had been looking for a way to replace the obsolete hardware that would not require much in the way of software / application updates.
A very old version of Oracle (7.3) is part of that medical device. There was no version of the DB that was an option for other OSs (at that time, for example, NT was not as reliable as needed - a requirement to reboot daily just did not cut it), there was no Linux version.
So, for now as part of my hobby, I'm just evaluating VM maturity with those applications that I am familiar with (and which I know highlight issues with the current VM).
On looking back at my notes, I realize that I did not keep track of the OpenBIOS versions used which would have been useful.
Also, I did not add it to my notes from 0.14 and later that the spurious syslog issue did exist. I thought that might be a useful troubleshooting path to follow. But, with the current questionable stability of Sparc32, I've held off.
I've noticed your comments about Sparc64. Does that mean I should try that? Or is your success contingent upon inclusion of your own patches (proprietary?)?
Correct. I haven't submitted the sparc64 patches upstream.
Right now I consider submitting upstream a subset which would allow running Linux. I think that would make sense: free version to run the free OS and a paid version to run a proprietary OS.
Here is some more detail about which version to use. There are two tables, one for Qemu in VirtualBox Ubuntu machine, another for Qemu in native Ubuntu machine.
Rows are Openbios version. Column is Qemu version. All are Sparc32, Solaris 8.
Notes are for booting of Solaris to the login prompt (unless otherwise noted).
X of Y means the boot was Ok X times out of Y attempts. The number (n) is a note about what happened during the unsuccessful boot.
When things seemed to be doing very will I did 10 attempts instead of 5.
Hmm, I tried to put this in a table using html "table", "tr" etc, but blogger.com did not like it. I guess it is not too readable.
Ubuntu inside VirtualBox
| 0.14.1 | 0.15.1 | 1.0.1 | 1.1rc1 (0511)
1047 | 3 of 5 (1), (2) | 0 of 5 (1) | 2 of 5 (2) | 8 of 10 (2)
1057(less 1056) | 3 of 5 (2) | 0 of 5 (1) | 3 of 5 (2) | 9 of 10 (2)
Native Ubuntu
| 0.14.1 | 0.15.1 | 1.0.1 | 1.1rc1 (0514)
1047 | 3 of 5 (2) | 4 of 5 (3) | 1 of 5 (2) | 3 of 5 (2), (3)
1057(less 1056) | 8 of 9 (3) | 4 of 5 (2) | 0 of 5 (2) | 3 of 5 (2), (4)
(1) Qemu Segmentation Fault
(2) Boot hangs at "Hostname: foo"
(3) Boot hangs at "Starting the efdaemon"
(4) Boot hangs after multicast configuration
Post a Comment