unaccelerated qemu is broken

Bug #975240 reported by Serge Hallyn
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
qemu-kvm (Debian)
Fix Released
Unknown
qemu-kvm (Ubuntu)
Fix Released
Critical
Serge Hallyn

Bug Description

accelerated kvm works fine, but unaccelerated it hangs. To reproduce:

wget http://people.canonical.com/~jamie/libvirt/qatest.tar.bz2
tar jxf qatest.tar.bzw
cd qatest
qemu-system-x86_64 -no-kvm -m 128 -monitor stdio -vnc :0 -vga cirrus -usb -drive file=qatest.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1

You can connect to the vm with 'gvncviewer :0'. Some time after it starts loading the initramfs, qemu locks up. Typing into the stdio monitor is hung.

Enabling kvm, the vm boots fine.

Changed in qemu-kvm (Ubuntu):
importance: Undecided → Critical
status: New → Confirmed
status: Confirmed → In Progress
assignee: nobody → Serge Hallyn (serge-hallyn)
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I can confirm this. Booting with this works fine:
LC_ALL=C PATH=/bin:/usr/sbin:/sbin:/bin /usr/bin/qemu-system-i386 -m 128 -usb -drive file=/tmp/qatest.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1

Booting with this does not:
LC_ALL=C PATH=/bin:/usr/sbin:/sbin:/bin /usr/bin/qemu-system-i386 -no-kvm -m 128 -usb -drive file=/tmp/qatest.img,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0,bootindex=1

FWIW, if I go into the grub menu and remove 'quiet splash' I see it stops at:
ENABLING IO-APIC IRQs

Adding '-no-acpi' allows it to boot.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Fixed upstream, fix bisected to 62db8bf39b8a0e3edb631a3d0e5bde840c780fcf: ARM: exynos4210: PWM support. That doesn't quite seem right, let me verify...

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

No, still broken with that commit, apparently I took a wrong turn while bisecting.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

I believe 30628cb12de2e35d87cb04194113341b6a8922b2 is the fix

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

nope.

unfortunately for bisecting, it appears to not *always* hang.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

ce967e2f33861b0e17753f97fa4527b5943c94b6 in qemu definately fixes it.

trying to cherrypick the equivalent commit from qemu-kvm upstream, though it appears to have pieces ofanother commit included and does not cherrypick cleanly.

Dave Walker (davewalker)
tags: added: rls-mgr-p-tracking
Changed in qemu-kvm (Debian):
status: Unknown → New
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Per discussion on #qemu, the proposed fix simply enforces -no-hpet when kvm acceleration is not used.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu11

---------------
qemu-kvm (1.0+noroms-0ubuntu11) precise; urgency=low

  * debian/patches/disable-hpet-for-tcg.patch: implicitly set -no-hpet
    when using tcg (non-accelerated qemu). (LP: #975240)
 -- Serge Hallyn <email address hidden> Mon, 09 Apr 2012 11:06:36 -0500

Changed in qemu-kvm (Ubuntu):
status: In Progress → Fix Released
Changed in qemu-kvm (Debian):
status: New → Fix Committed
Changed in qemu-kvm (Debian):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.