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
