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

Attachment: signature.asc
Description: PGP signature

Reply via email to