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