SVN revision 4183 compiled from source exhibits the same behaviour, but the qemu from etch (leaving everything else except the sparc bios that needs newer qemu at lenny or unstable (trying to see if newer version fixed lenny)) doesn't appear to. That is not entirely clear yet because determining it's okay takes longer than it fails.
The disk image I have for 98se (which I regenerated after I first experienced problems, think maybe it was the image), consistently dies (the vm that is, not a crash but a vm hang with mouse and keyboard in host unresponsive, but switching vt brings back X response and keyboard) within the install or two (varies) of a couple of 98se updates. Of course this session that is working with the etch qemu could just be luck, but considering how consistently quickly the newer qemu dies, I am optimistic. At a wild guess I would think the assembler rewriting that has been happening is the culprit. For my next trick I will try the current -testing qemu and see what happens. If it works then the problem is -unstable (0.9.1) and it means I would have upgraded qemu to -unstable but forgotten that I had, before the problems started, probably for some other issue. Still since -unstable goes into -testing even if -testing works, a broken -unstable isn't good (actually it's upstream which makes things more difficult). -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Weblog http://cshore.wordpress.com
signature.asc
Description: PGP signature