6.3/amd64: linux guest hangs if kqemu is used

Juergen Lock nox at jelal.kn-bremen.de
Wed Jul 9 20:52:41 UTC 2008


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
> 
> There are no messages on qemu output or in system log.
> qemu uses 100% CPU.
> Ctrl+Alt+2 works, I can execute commands in qemu console.
> BTW, info kqemu says "enabled for user code".
> 
> Guest console messages:
> ...
> PCI: Using ACPI for IRQ routing
> PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a
> report
> NetLabel: Initializing
> NetLabel:  domain hash size = 128
> NetLabel:  protocols = UNLABELED CIPSOv4
> NetLabel:  unlabeled traffic allowed by default
> PCI-GART: No AMD northbridge found.
> !
> ! kqemu hang is here !
> !
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 6, 262144 bytes)
> TCP established hash table entries: 131072 (order: 9, 2097152 bytes)
> TCP bind hash table entries: 65536 (order: 8, 1048576 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> checking if image is initramfs...<7>Switched to high resolution mode on
> CPU 0
> Clocksource tsc unstable (delta = 778613351 ns)
>  it is
> ...
> 
> -- 
> Andriy Gapon

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

 HTH,
	Juergen


More information about the freebsd-emulation mailing list