[Qemu-devel] apparently missing yet another notify_event()

[Qemu-devel] apparently missing yet another notify_event()

[Michael Tokarev]

There's a new bugreport filed against qemu-kvm in debian,
which looks very similar to what we already had before --
https://bugs.launchpad.net/qemu/+bug/1021649
which were fixed by adding qemu_notify_event() call.
Later on these qemu_notify_event() calls become unnecessary
as far as I remember.

But here is a new one.

 qemu -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty

This will hang with 100% CPU usage until something is sent
to the pty.  <Enter> key is enough.

It does the same on qemu and kvm, with and without -enable-kvm,
and it looks pretty much like another forgotten notify_event.
And it happens on 1.1 and 1.2-tobe (today qemu/master), so should
be fixed before 1.2 is released.

Note: libvirt uses pty-redirected serial port heavily, and this
is where the users are hit, exactly.

The longer -serial specification (-chardev pty, -device isa-serial)
triggers it too.

What's missing this time?

(http://bugs.debian.org/686524 is the original bugreport).

Thanks,

/mjt

Re: [Qemu-devel] apparently missing yet another notify_event()

[Paolo Bonzini]

Il 03/09/2012 20:13, Michael Tokarev ha scritto:
> There's a new bugreport filed against qemu-kvm in debian,
> which looks very similar to what we already had before --
> https://bugs.launchpad.net/qemu/+bug/1021649
> which were fixed by adding qemu_notify_event() call.
> Later on these qemu_notify_event() calls become unnecessary
> as far as I remember.
> 
> But here is a new one.
> 
>  qemu -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty
> 
> This will hang with 100% CPU usage until something is sent
> to the pty.  <Enter> key is enough.
> 
> It does the same on qemu and kvm, with and without -enable-kvm,
> and it looks pretty much like another forgotten notify_event.
> And it happens on 1.1 and 1.2-tobe (today qemu/master), so should
> be fixed before 1.2 is released.
> 
> Note: libvirt uses pty-redirected serial port heavily, and this
> is where the users are hit, exactly.
> 
> The longer -serial specification (-chardev pty, -device isa-serial)
> triggers it too.
> 
> What's missing this time?

Could it be this one?

<http://permalink.gmane.org/gmane.comp.emulators.qemu/168209>

Paolo

Re: [Qemu-devel] apparently missing yet another notify_event()

[Michael Tokarev]

On 04.09.2012 10:53, Paolo Bonzini wrote:
> Il 03/09/2012 20:13, Michael Tokarev ha scritto:
[]
>>  qemu -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty
>>
>> This will hang with 100% CPU usage until something is sent
>> to the pty.  <Enter> key is enough.
[]
> Could it be this one?
> 
> <http://permalink.gmane.org/gmane.comp.emulators.qemu/168209>

Removing this "pending" initialization fixes this problem too.

Thanks,

/mjt

Re: [Qemu-devel] apparently missing yet another notify_event()

[Michael Tokarev]

On 04.09.2012 10:58, Michael Tokarev wrote:
> On 04.09.2012 10:53, Paolo Bonzini wrote:
>> Il 03/09/2012 20:13, Michael Tokarev ha scritto:
> []
>>>  qemu -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty
>>>
>>> This will hang with 100% CPU usage until something is sent
>>> to the pty.  <Enter> key is enough.
> []
>> Could it be this one?
>>
>> <http://permalink.gmane.org/gmane.comp.emulators.qemu/168209>
> 
> Removing this "pending" initialization fixes this problem too.

Actually it is not the same thing, and applying this path
does not solve the originak issue for me, neither does
updating to 1.2.0 help.

But it looks like I wasn't correct with the initial diagnostic.
Qemu (either 1.1 or 1.2) just sleeps for a few moments (about
2 seconds) after startup with my command line option, and I
thought it is stalled.

The actual problem appears to be qemu-kvm-specific, it does not
affect qemu (with or without -enable-kvm).

 qemu-kvm -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty

This hangs till I send a char to the pty.

/mjt

Re: [Qemu-devel] apparently missing yet another notify_event()

[Michael Tokarev]

On 14.09.2012 18:17, Michael Tokarev wrote:
> On 04.09.2012 10:58, Michael Tokarev wrote:
>> On 04.09.2012 10:53, Paolo Bonzini wrote:
>>> Il 03/09/2012 20:13, Michael Tokarev ha scritto:
>> []
>>>>  qemu -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty
>>>>
>>>> This will hang with 100% CPU usage until something is sent
>>>> to the pty.  <Enter> key is enough.
>> []
>>> Could it be this one?
>>>
>>> <http://permalink.gmane.org/gmane.comp.emulators.qemu/168209>
>>
>> Removing this "pending" initialization fixes this problem too.
> 
> Actually it is not the same thing, and applying this path
> does not solve the originak issue for me, neither does
> updating to 1.2.0 help.
> 
> But it looks like I wasn't correct with the initial diagnostic.
> Qemu (either 1.1 or 1.2) just sleeps for a few moments (about
> 2 seconds) after startup with my command line option, and I
> thought it is stalled.
> 
> The actual problem appears to be qemu-kvm-specific, it does not
> affect qemu (with or without -enable-kvm).
> 
>  qemu-kvm -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty
> 
> This hangs till I send a char to the pty.

And it is even _more_ twisted than that.

It depends on the timing.  If I connect to the pty "too soon",
it will not stall.

But if I wait for ~2 seconds or more before connecting, both
qemu and qemu-kvm (and so current qemu/master too) will hang,
requiring a keypress on the pty for the guest to start booting.

Hwell.

/mjt

Re: [Qemu-devel] apparently missing yet another notify_event()

[Michael Tokarev]

On 14.09.2012 18:47, Michael Tokarev wrote:
[]
>>  qemu-kvm -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty
>>
>> This hangs till I send a char to the pty.
> 
> And it is even _more_ twisted than that.
> 
> It depends on the timing.  If I connect to the pty "too soon",
> it will not stall.
> 
> But if I wait for ~2 seconds or more before connecting, both
> qemu and qemu-kvm (and so current qemu/master too) will hang,
> requiring a keypress on the pty for the guest to start booting.

(For upstream qemu, it only happens with -enable-kvm, not in
tcg mode).

> Hwell.
> 
> /mjt

Re: [Qemu-devel] apparently missing yet another notify_event()

[Michael Tokarev]

On 14.09.2012 18:47, Michael Tokarev wrote:
[]
>>
>>  qemu-kvm -nographic -kernel /boot/vmlinuz-$(uname -r) -append console=ttyS0 -serial pty
>>
>> This hangs till I send a char to the pty.
> 
> And it is even _more_ twisted than that.
> 
> It depends on the timing.  If I connect to the pty "too soon",
> it will not stall.
> 
> But if I wait for ~2 seconds or more before connecting, both
> qemu and qemu-kvm (and so current qemu/master too) will hang,
> requiring a keypress on the pty for the guest to start booting.

(qemu only in kvm mode).

I bisected this to:

commit 67c5322d7000fd105a926eec44bc1765b7d70bdd
Author: Anthony Liguori <aliguori@us.ibm.com>
Date:   Sun Apr 1 14:03:21 2012 -0500

    serial: fix retry logic

    I'm not sure if the retry logic has ever worked when not using FIFO mode.  I
    found this while writing a test case although code inspection confirms it is
    definitely broken.

    The TSR retry logic will never actually happen because it is guarded by an
    'if (s->tsr_rety > 0)' but this is the only place that can ever make the
    variable greater than zero.  That effectively makes the retry logic an 'if (0)'.

    I believe this is a typo and the intention was >= 0.  Once this is fixed though,
    I see double transmits with my test case.  This is because in the non FIFO
    case, serial_xmit may get invoked while LSR.THRE is still high because the
    character was processed but the retransmit timer was still active.

    We can handle this by simply checking for LSR.THRE and returning early.  It's
    possible that the FIFO paths also need some attention.

    Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

which is part of 1.1 development cycle.  Reverting this commit
from 1.2.0 fixes the issue there.

/mjt