qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jamie Heilman
Subject: Re: [Qemu-devel] [Bug 1021649] Re: qemu 1.1.0 waits for a keypress at boot
Date: Sat, 4 Aug 2012 04:58:01 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]