Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
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/
Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
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
Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
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
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.stabell...@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.stabell...@eu.citrix.com Acked-by: Paul Brook p...@codesourcery.com Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
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.stabell...@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.stabell...@eu.citrix.com Acked-by: Paul Brook p...@codesourcery.com Signed-off-by: Anthony Liguori aligu...@us.ibm.com
Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
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
