All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Anthony Liguori <aliguori@us.ibm.com>,
	qemu-devel <qemu-devel@nongnu.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Subject: Re: [Qemu-devel] apparently missing yet another notify_event()
Date: Fri, 14 Sep 2012 19:47:31 +0400	[thread overview]
Message-ID: <50535193.9080903@msgid.tls.msk.ru> (raw)
In-Reply-To: <5053438F.9000601@msgid.tls.msk.ru>

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

      parent reply	other threads:[~2012-09-14 15:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-03 18:13 [Qemu-devel] apparently missing yet another notify_event() Michael Tokarev
2012-09-04  6:53 ` Paolo Bonzini
2012-09-04  6:58   ` Michael Tokarev
2012-09-14 14:17     ` Michael Tokarev
2012-09-14 14:47       ` Michael Tokarev
2012-09-14 14:49         ` Michael Tokarev
2012-09-14 15:47         ` Michael Tokarev [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50535193.9080903@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=aliguori@us.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefano.stabellini@eu.citrix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.