qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: kqemu in x86_64: (host) exception 0x0d in monitor space


From: Anthony Liguori
Subject: [Qemu-devel] Re: kqemu in x86_64: (host) exception 0x0d in monitor space
Date: Fri, 11 Aug 2006 10:50:30 -0500
User-agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))

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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]