6.3/amd64: linux guest hangs if kqemu is used

Andriy Gapon avg at icyb.net.ua
Fri Jul 11 14:40:39 UTC 2008


on 11/07/2008 17:37 Andriy Gapon said the following:
> on 09/07/2008 23:49 Juergen Lock said the following:
>> On Wed, Jul 09, 2008 at 08:16:18PM +0300, Andriy Gapon wrote:
>>> This report is quite low on details.
>>>
>>> My system is 6.3-RELEASE amd64.
>>> I have qemu-0.9.1_9 and kqemu-kmod-1.3.0.p11_9.
>>> Guest is 2.6.25.9-76.fc9.x86_64.
>>>
>>> kqemu.ko and aio.ko are loaded.
>>>
>>> Run like this is OK:
>>> qemu-system-x86_64 -no-kqemu -m 640 -hda box1.img -net nic -net tap
>>>
>>> Run like this - guest hangs during boot:
>>> qemu-system-x86_64 -m 640 -hda box1.img -net nic -net tap
> [snip]
>> It is true kqemu works less well on amd64 than on 32 bit hosts...
>> (tho things have improved in qemu svn especially for 32 bit guests - the
>> snapshot I just updated the qemu-devel port to can now also use kqemu
>> for the 32 bit `qemu'.)
>>
>>  Oh, if you host is SMP you probably need to pass `notsc' to your
>> guest linux kernel, if its not that or you still get problems later
>> you can still try the qemu-devel port (which also uses a new kqemu as
>> mentioned in ports/UPDATING), but otherwise I guess you can only report
>> the bug upstream i.e. on the qemu-devel mailinglist:
>> 	http://lists.gnu.org/mailman/listinfo/qemu-devel
> 
> Jürgen,
> 
> thank you very much for the advice!
> notsc allowed linux boot to proceed past the hand point, but later qemu
> process aborted with the following output:
> 
> $ qemu-system-x86_64 -m 800 -hda box1.img -net nic -net tap
> RAX=00007f7e43358000 RBX=00007f7e43358560 RCX=0000003c10615c5a
> RDX=0000000000000001
> RSI=0000003c10618934 RDI=0000000000000000 RBP=00007f7e43358000
> RSP=00007fff4b3573b0
> R8 =00000000ffffffff R9 =0000000000000000 R10=0000000000000022
> R11=0000000000010246
> R12=0000000000000000 R13=0000000000000000 R14=0000000000000010
> R15=0000000000000001
> RIP=0000003c1060a667 RFL=00010206 [-----P-] CPL=3 II=0 A20=1 SMM=0 HLT=0
> ES =0000 0000000000000000 00000000 00000000
> CS =0033 0000000000000000 ffffffff 00affb00
> SS =002b 0000000000000000 ffffffff 00cff300
> DS =0000 0000000000000000 00000000 00000000
> FS =0000 0000000000000000 00000000 00000000
> GS =0000 0000000000000000 00000000 00000000
> LDT=0000 0000000000000000 00000000 00008000
> TR =0040 ffff810001009900 00002087 00008900
> GDT=     ffffffff81456000 00000080
> IDT=     ffffffff814c2000 00000fff
> CR0=8005003b CR2=00007f7e43358028 CR3=0000000030dfc000 CR4=000006e0
> Unsupported return value: 0xffffffff
> 
> This happened while starting userland daemons. I used "interactive
> startup" and the problem occurred on sendmail (sm-client) [!].
> The problem is reliably reproducible.
> 
> P.S. I disabled sendmail, services startup proceeded few more steps and
> then qemu reported same error again ("Unsupported return value") on some
> other service. I gave up after that.
> 

Just noticed - the following was in system log:
kqemu: aborting: Unexpected exception 0x0d in monitor space
err=0000 CS:EIP=f180:00000000f0002806 SS:SP=0000:00000000f00c7e00


-- 
Andriy Gapon


More information about the freebsd-emulation mailing list