On Fri, 11 Aug 2006 07:57:41 +0100, J M Cerqueira Esteves wrote: > Greetings > > Summary: qemu-system-x86_64 with kqemu (running under Ubuntu on a Athlon > 64) crashes while installing a guest Debian amd64 testing (etch) system, > with the host reporting (in kernel logs): > kqemu: aborting: Unexpected exception 0x0d in monitor space
Sounds like a kqemu bug. 0x0d == 14 == page fault. The only person who can help you here is Fabrice... Regards, Anthony Liguori > > > Host CPU: AMD Athlon 64 3500+ (machine: HP dx5150 MT) Host operating > system: Ubuntu 6.06 LTS Host kernel: one of the Ubuntu pre-packaged ones, > 2.6.15-26-amd64-k8 (SMP PREEMPT) > > VDE: 'backported' (just rebuilding the package) > from Debian testing's vde 1.5.11-1. > QEMU: 0.8.2, configured with -cc=gcc-3.4 --enable-alsa kqemu: 1.3.0pre9 > > I tried to install Debian amd64 testing (etch) from a snapshot netinst iso > image downloaded yesterday, invoking > > vdeq qemu-system-x86_64 \ > -pidfile /srv/qemu/nisaba.pid \ > -m 160 \ > -net nic,vlan=0,model=rtl8139,macaddr=4A:4D:23:00:00:01 \ -net > vde,vlan=0,sock=/var/run/vde/tap-vde-1.ctl \ -hda /srv/qemu/$NAME.qcow \ > -cdrom /srv/ark/cd/debian-testing-amd64-netinst-20060810.iso \ > -boot d > > Booted in expert mode, chose language, keyboard layout, country, locale > parameters, and just after I chose "detect and mount cdrom" qemu crashed > (apparently immediately after (very briefly) showing a progress bar with > "detecting hardware to find cd-rom drives"), with the (host-side) output > > ES =0000 0000000000000000 00000000 00000000 CS =0033 0000000000000000 > ffffffff 00affa00 SS =002b 0000000000000000 ffffffff 00cff200 DS =0000 > 0000000000000000 00000000 00000000 FS =0000 0000000000000000 00000000 > 00000000 GS =0000 0000000000000000 00000000 00000000 LDT=0000 > 0000000000000000 00000000 00008000 TR =0040 ffffffff8030e000 0000206f > 80008930 GDT= ffffffff8030c000 00000080 > IDT= ffffffff8030d000 00001000 > CR0=8005003b CR2=00002b599766f800 CR3=00000000074c4000 CR4=000006e0 > Unsupported return value: 0xffffffff > > In a second attempt I got > > RAX=00002b80af1d7d20 RBX=00002b80af1d49e8 RCX=0000000000000008 > RDX=0000000000000008 > RSI=00002b80af393800 RDI=000000000053f478 RBP=00007fffff9fa2c0 > RSP=00007fffff9fa1d8 > R8 =00002b80af393800 R9 =0000000000000000 R10=000000000053f478 > R11=0000000000000002 > R12=0000000000000000 R13=0000000000000005 R14=00002b80af0d54b0 > R15=0000000000402a18 > RIP=00002b80af0ce390 RFL=00010287 [--S--PC] CPL=3 II=0 A20=1 HLT=0 ES > =0000 0000000000000000 00000000 00000000 CS =0033 0000000000000000 > ffffffff 00affa00 SS =002b 0000000000000000 ffffffff 00cff200 DS =0000 > 0000000000000000 00000000 00000000 FS =0000 0000000000000000 00000000 > 00000000 GS =0000 0000000000000000 00000000 00000000 LDT=0000 > 0000000000000000 00000000 00008000 TR =0040 ffffffff8030e000 0000206f > 80008930 GDT= ffffffff8030c000 00000080 > IDT= ffffffff8030d000 00001000 > CR0=8005003b CR2=00002b80af393800 CR3=0000000007b48000 CR4=000006e0 > Unsupported return value: 0xffffffff > > > For every such test, the host's dmesg and kernel logs reported the > following: > > kqemu: aborting: Unexpected exception 0x0d in monitor space err=0000 > CS:EIP=f180:00000000f0002806 SS:SP=0000:00000000f00c7e00 > > > The above crash does not happen when qemu-system-x86_64 is invoked with > the additional option "-no-kqemu". > > In case this issue is already known: is there any way to avoid this crash > (maybe some boot time parameter for the Debian guest kernel?) without > disabling kqemu? > > Any suggestions for additional information gathering here which could help > solve this issue? > > > Best regards (and *many* thanks for QEMU) > > J Esteves _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
