[Qemu-devel] [Bug 1021649] [NEW] qemu 1.1.0 waits for a keypress at boot

[Qemu-devel] [Bug 1021649] [NEW] qemu 1.1.0 waits for a keypress at boot

[Richard W.M. Jones]

Public bug reported:

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.

** Affects: qemu
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Richard W.M. Jones]

** Attachment added: "test-qemu.sh"
   https://bugs.launchpad.net/bugs/1021649/+attachment/3214808/+files/test-qemu.sh

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Richard W.M. Jones]

Also affects upstream qemu from git.

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Richard W.M. Jones]

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Anthony Liguori]

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Richard W.M. Jones]

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

** Changed in: qemu
       Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Invalid

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Michael Tokarev]

** Changed in: qemu
       Status: Invalid => New

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Michael Tokarev]

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

Thanks,

/mjt


** Bug watch added: Debian Bug tracker #680719
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680719

** Also affects: qemu-kvm (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680719
   Importance: Unknown
       Status: Unknown

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New
Status in “qemu-kvm” package in Debian:
  Unknown

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Bug Watch Updater]

** Changed in: qemu-kvm (Debian)
       Status: Unknown => Incomplete

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New
Status in “qemu-kvm” package in Debian:
  Incomplete

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Richard W.M. Jones]

Well that's very interesting because one of the patches we have added in
Fedora is:

http://pkgs.fedoraproject.org/gitweb/?p=qemu.git;a=blob;f=0001-qemu-kvm-
Add-missing-default-machine-
options.patch;h=e785a708d0bf0861c2f0f1777b8cc477d12fe145;hb=HEAD

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New
Status in “qemu-kvm” package in Debian:
  Incomplete

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Michael Tokarev]

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:
  NULL
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.

Thanks,

/mjt

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  New
Status in “qemu-kvm” package in Debian:
  Incomplete

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Michael Tokarev]

** Changed in: qemu
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Debian:
  Incomplete

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Bug Watch Updater]

** Changed in: qemu-kvm (Debian)
       Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Debian:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Michael Tokarev]

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

7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
commit 7c7db75576bd5a31508208f153c5aada64b2c8df
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
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
    value;
    
    Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Acked-by: Paul Brook <paul@codesourcery.com>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Debian:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Michael Tokarev]

Stefano, Paul, can you take a look please?

https://bugs.launchpad.net/bugs/1021649

Thanks,

/mjt

On 25.07.2012 12:25, Michael Tokarev wrote:
> Jamie Heilman (the debian bug #680719 reporter) bisected this issue to
> this commit:
> 
> 7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
> commit 7c7db75576bd5a31508208f153c5aada64b2c8df
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> 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
>     value;
>     
>     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>     Acked-by: Paul Brook <paul@codesourcery.com>
>     Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> 

Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Stefano Stabellini]

On Wed, 25 Jul 2012, Michael Tokarev wrote:
> Stefano, Paul, can you take a look please?
> 
> https://bugs.launchpad.net/bugs/1021649

That is a very good bug triage that you did!

However "main_loop_wait: block indefinitely" only increases the maximum
select timeout of QEMU's main_loop.
That mean that if one or more emulators have bugs and don't get
notifications correctly they might hang.
The reason why it only reproduces with nographic is that both sdl and vnc
introduce a gui_timer that wakes QEMU up every 30ms.

So the question is: why is kernel_irqchip=on required to repro the bug?
It strikes me as a bug in kernel_irqchip that prevents QEMU from being
waken up when it should.

CC'ing Avi.


> Thanks,
> 
> /mjt
> 
> On 25.07.2012 12:25, Michael Tokarev wrote:
> > Jamie Heilman (the debian bug #680719 reporter) bisected this issue to
> > this commit:
> > 
> > 7c7db75576bd5a31508208f153c5aada64b2c8df is the first bad commit
> > commit 7c7db75576bd5a31508208f153c5aada64b2c8df
> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > 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
> >     value;
> >     
> >     Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >     Acked-by: Paul Brook <paul@codesourcery.com>
> >     Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> > 
> 
> 

Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Avi Kivity]

On 07/25/2012 02:12 PM, Stefano Stabellini wrote:
> On Wed, 25 Jul 2012, Michael Tokarev wrote:
>> Stefano, Paul, can you take a look please?
>> 
>> https://bugs.launchpad.net/bugs/1021649
> 
> That is a very good bug triage that you did!
> 
> However "main_loop_wait: block indefinitely" only increases the maximum
> select timeout of QEMU's main_loop.
> That mean that if one or more emulators have bugs and don't get
> notifications correctly they might hang.
> The reason why it only reproduces with nographic is that both sdl and vnc
> introduce a gui_timer that wakes QEMU up every 30ms.
> 
> So the question is: why is kernel_irqchip=on required to repro the bug?
> It strikes me as a bug in kernel_irqchip that prevents QEMU from being
> waken up when it should.

kernel_irqchip=on means that many guest timers and interrupt sources are
removed from qemu and implemented in the kernel, so qemu sees a lot less
wakeups and hangs.  With kernel_irqchip=off the APIC or PIT wakes up
qemu, taking the place of the keypress.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Jamie Heilman]

Avi Kivity wrote:
> On 07/25/2012 02:12 PM, Stefano Stabellini wrote:
> > On Wed, 25 Jul 2012, Michael Tokarev wrote:
> >> Stefano, Paul, can you take a look please?
> >> 
> >> https://bugs.launchpad.net/bugs/1021649
> > 
> > That is a very good bug triage that you did!
> > 
> > However "main_loop_wait: block indefinitely" only increases the maximum
> > select timeout of QEMU's main_loop.
> > That mean that if one or more emulators have bugs and don't get
> > notifications correctly they might hang.
> > The reason why it only reproduces with nographic is that both sdl and vnc
> > introduce a gui_timer that wakes QEMU up every 30ms.
> > 
> > So the question is: why is kernel_irqchip=on required to repro the bug?
> > It strikes me as a bug in kernel_irqchip that prevents QEMU from being
> > waken up when it should.
> 
> kernel_irqchip=on means that many guest timers and interrupt sources are
> removed from qemu and implemented in the kernel, so qemu sees a lot less
> wakeups and hangs.  With kernel_irqchip=off the APIC or PIT wakes up
> qemu, taking the place of the keypress.

You're not implying the key press waking up qemu was a planned thing
are you?  Becuase it doesn't work at all when console is a -chardev pty
device.  With -machine kernel_irqchip=on -display none -chardev pty,...
qemu simply hangs and consumes as much cpu as it can, attaching to the
terminal and sending data does nothing.  I'd hate to think that's the
new normal.

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/

Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Avi Kivity]

On 08/04/2012 07:58 AM, Jamie Heilman wrote:
> Avi Kivity wrote:
>> On 07/25/2012 02:12 PM, Stefano Stabellini wrote:
>> > On Wed, 25 Jul 2012, Michael Tokarev wrote:
>> >> Stefano, Paul, can you take a look please?
>> >> 
>> >> https://bugs.launchpad.net/bugs/1021649
>> > 
>> > That is a very good bug triage that you did!
>> > 
>> > However "main_loop_wait: block indefinitely" only increases the maximum
>> > select timeout of QEMU's main_loop.
>> > That mean that if one or more emulators have bugs and don't get
>> > notifications correctly they might hang.
>> > The reason why it only reproduces with nographic is that both sdl and vnc
>> > introduce a gui_timer that wakes QEMU up every 30ms.
>> > 
>> > So the question is: why is kernel_irqchip=on required to repro the bug?
>> > It strikes me as a bug in kernel_irqchip that prevents QEMU from being
>> > waken up when it should.
>> 
>> kernel_irqchip=on means that many guest timers and interrupt sources are
>> removed from qemu and implemented in the kernel, so qemu sees a lot less
>> wakeups and hangs.  With kernel_irqchip=off the APIC or PIT wakes up
>> qemu, taking the place of the keypress.
> 
> You're not implying the key press waking up qemu was a planned thing
> are you?  

I am not.

> Becuase it doesn't work at all when console is a -chardev pty
> device.  With -machine kernel_irqchip=on -display none -chardev pty,...
> qemu simply hangs and consumes as much cpu as it can, attaching to the
> terminal and sending data does nothing.  I'd hate to think that's the
> new normal.

It's not.

-- 
error compiling committee.c: too many arguments to function

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Georg Hopp]

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

** Patch added: "remove-7c7db75.patch"
   https://bugs.launchpad.net/qemu/+bug/1021649/+attachment/3235773/+files/remove-7c7db75.patch

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Debian:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Michael Tokarev]

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Debian:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Paolo Bonzini]

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?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in Debian:
  Confirmed

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Jamie Heilman]

Paolo 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?

Works for me with ioeventfd=off. (Debian's qemu-kvm 1.1.0+dfsg-3 on amd64) 

-- 
Jamie Heilman                     http://audible.transient.net/~jamie/

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Bug Watch Updater]

** Changed in: qemu-kvm (Debian)
       Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Confirmed
Status in “qemu-kvm” package in 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Thomas Huth]

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Incomplete
Status in qemu-kvm package in 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Richard Jones]

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Fix Released
Status in qemu-kvm package in 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions

[Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot

[Paolo Bonzini]

** Changed in: qemu
       Status: Incomplete => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1021649

Title:
  qemu 1.1.0 waits for a keypress at boot

Status in QEMU:
  Fix Released
Status in qemu-kvm package in 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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1021649/+subscriptions