qemu 1.1.0 waits for a keypress at boot

Bug #1021649 reported by Richard W.M. Jones on 2012-07-06
This bug affects 3 people
Affects Status Importance Assigned to Milestone
qemu-kvm (Debian)
Fix Released

Bug Description

qemu 1.1.0 waits for a keypress at boot. Please don't ever do this.

Try the attached test script. When run it will initially print nothing, until you hit a key on the keyboard.

Removing -nographic fixes the problem.

Using virtio-scsi instead of virtio-blk fixes the problem.

Also affects upstream qemu from git.

Using -device sga fixes the problem, but also means I cannot see what it's trying to wait for.

I don't see this problem. Are you sure you're not using the bios from Fedora? Perhaps it's configured incorrectly.

Yes, I tested it again and it does look like it's loading a Fedora ROM. Dammit ...

Changed in qemu:
status: New → Invalid
Changed in qemu:
status: Invalid → New

This is a bit more interesting. I've got a bugreport in debian about the same thing, and verified it in debian qemu-kvm package - indeed, with -nographics, upstream 1.1 qemu and qemu-kvm refuses to boot without an extra keypress, but only when kernel_irqchip is enabled. Ie, the following requires keypress:

  qemu -machine pc,accel=kvm,kernel_irqchip=on -nographics
  qemu-kvm -nographics

and the following does not:

  qemu -machine pc,accel=kvm -nographics
  qemu-kvm -no-kvm-irqchip -nographics



Changed in qemu-kvm (Debian):
status: Unknown → Incomplete

when the guest is waiting for the keypress, it is sitting in KVM_RUN ioctl and eating 100% CPU. When enabling Seabios debugging, the last lines before the stall is this:

Returned 57344 bytes of ZoneHigh
e820 map has 7 items:
  0: 0000000000000000 - 000000000009dc00 = 1 RAM
  1: 000000000009dc00 - 00000000000a0000 = 2 RESERVED
  2: 00000000000f0000 - 0000000000100000 = 2 RESERVED
  3: 0000000000100000 - 000000001fffe000 = 1 RAM
  4: 000000001fffe000 - 0000000020000000 = 2 RESERVED
  5: 00000000feffc000 - 00000000ff000000 = 2 RESERVED
  6: 00000000fffc0000 - 0000000100000000 = 2 RESERVED
enter handle_19:
Booting from Hard Disk...

So far it only happens when "booting" from a VIRTIO hard disk. With IDE disk it boots fine.

So, in order for it to actually stall,

  qemu -machine pc,accel=kvm,kernel_irqchip=on -drive file=foo,if=virtio -nographics

is needed.



Changed in qemu:
status: New → Confirmed
Changed in qemu-kvm (Debian):
status: Incomplete → Confirmed

Jamie Heilman (the debian bug #680719 reporter) bisected this issue to this commit:

7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
commit 7c7db75576bd5a31508208f153c5aada64b2c8df
Author: Stefano Stabellini <email address hidden>
Date: Fri Apr 13 19:35:04 2012 +0100

    main_loop_wait: block indefinitely

    - remove qemu_calculate_timeout;

    - explicitly size timeout to uint32_t;

    - introduce slirp_update_timeout;

    - pass NULL as timeout argument to select in case timeout is the maximum

    Signed-off-by: Stefano Stabellini <email address hidden>
    Acked-by: Paul Brook <email address hidden>
    Signed-off-by: Anthony Liguori <email address hidden>

Georg Hopp (w-reorg-h) wrote :

I encountered the same thing and created a patch that fixes the problem for me.

This is not a real fix. All i have done is the following:
- Clone the repo.
- Get a reverse diff for the commit in question "git diff 7c7db75..4ffd16f >foo1.patch".
- Try to apply this on master "patch <foo1.patch" and skip all files that could not be found.
- And finally do a "git diff >remove-7c7db75.patch"

As i am a gentoo user i applied this patch within my ebuild and

This is definitely a wrong way to "fix" this issue.

Paolo Bonzini (bonzini) wrote :

The patch at http://permalink.gmane.org/gmane.comp.emulators.qemu/162828 fixes it for ioeventfd=on (the bug is that the ioeventfd is not added to the select() arguments), but I and Avi disagreed on whether ioeventfd=off works. :)

Jamie/Richard/Georg, can you test your respective reproducers without any patch but with -global virtio-blk-pci.ioeventfd=off?

Changed in qemu-kvm (Debian):
status: Confirmed → Fix Released
Thomas Huth (th-huth) wrote :

Can this issue still be reproduced with the latest version of QEMU, or can we close this bug nowadays?

Changed in qemu:
status: Confirmed → Incomplete
Richard Jones (rjones-redhat) wrote :

No this refers to a very old version of qemu. This bug should be closed.

Paolo Bonzini (bonzini) on 2016-11-10
Changed in qemu:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments

Remote bug watches

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