From: Jan Kiszka <jan.kiszka@web.de>
To: Juergen Lock <nox@jelal.kn-bremen.de>
Cc: "Olivier Cochard-Labbé" <olivier@cochard.me>,
freebsd-current@FreeBSD.org, qemu-devel@nongnu.org,
"Stefano Stabellini" <stefano.stabellini@eu.citrix.com>
Subject: [Qemu-devel] Re: qemu serial: lost tx irqs (affectig FreeBSD's new uart(4) driver)
Date: Sat, 12 Sep 2009 19:00:57 +0200 [thread overview]
Message-ID: <4AABD3C9.7050900@web.de> (raw)
In-Reply-To: <20090912165222.GA38048@triton8.kn-bremen.de>
[-- Attachment #1: Type: text/plain, Size: 3865 bytes --]
Juergen Lock wrote:
> On Sat, Sep 12, 2009 at 02:26:51PM +0200, Jan Kiszka wrote:
>> Juergen Lock wrote:
>>> Hi!
>>>
>>> I got a report of FreeBSD guest's new uart(4) driver misbehaving in
>>> qemu again(?) (output stopping for no apparent reason), and now found
>>> out the problem is tx irqs (UART_IIR_THRI) are getting lost because
>>> serial_update_irq() checks for the rx condtion,
>>> ... if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR))
>>> first before checking for the tx irq condition,
>>> ... if ((s->ier & UART_IER_THRI) && s->thr_ipending)
>>> which at least in this case (FreeBSD 8 guest after doing
>>> set console="comconsole"
>>> at the loader prompt or when simply echo'ing text to /dev/ttyu0
>>> or typing to the serial port from cu(1) on a `regular' vga console)
>>> causes the second condition (.. && s->thr_ipending) to be never
>>> reached anymore, or only after a very long delay. Moving that
>>> condition up so it is checked first like this,
>>>
>>> Index: qemu/hw/serial.c
>>> @@ -189,7 +188,9 @@ static void serial_update_irq(SerialStat
>>> {
>>> uint8_t tmp_iir = UART_IIR_NO_INT;
>>>
>>> - if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) {
>>> + if ((s->ier & UART_IER_THRI) && s->thr_ipending) {
>>> + tmp_iir = UART_IIR_THRI;
>>> + } else if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) {
>>> tmp_iir = UART_IIR_RLSI;
>>> } else if ((s->ier & UART_IER_RDI) && s->timeout_ipending) {
>>> /* Note that(s->ier & UART_IER_RDI) can mask this interrupt,
>>> @@ -202,8 +203,6 @@ static void serial_update_irq(SerialStat
>>> } else if (s->recv_fifo.count >= s->recv_fifo.itl) {
>>> tmp_iir = UART_IIR_RDI;
>>> }
>>> - } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) {
>>> - tmp_iir = UART_IIR_THRI;
>>> } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA)) {
>>> tmp_iir = UART_IIR_MSI;
>>> }
>>>
>>> ...fixes the issue for me, but I'm not 100% sure if this might cause
>>> rx irqs to come (too?) late when a guest keeps sending while its
>>> receiving at the same time. Anyone care to comment? :)
>> The reordering violates the 16550A spec in that RX event overrules TX in
>> the IRQ status register. Maybe something else is wrong but it's not the
>> ordering in serial_update_irq.
>
> Well one problem seems to be the rx condition,
> ... if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR))
> is not enough to trigger an irq, yet still causes the following
> conditions not to be checked anymore at all. And ideed, fixing that
> seems to get my FreeBSD 8 guest back to working order as well:
>
> Index: qemu/hw/serial.c
> @@ -196,12 +195,10 @@ static void serial_update_irq(SerialStat
> * this is not in the specification but is observed on existing
> * hardware. */
> tmp_iir = UART_IIR_CTI;
> - } else if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR)) {
> - if (!(s->fcr & UART_FCR_FE)) {
> - tmp_iir = UART_IIR_RDI;
> - } else if (s->recv_fifo.count >= s->recv_fifo.itl) {
> - tmp_iir = UART_IIR_RDI;
> - }
> + } else if ((s->ier & UART_IER_RDI) && (s->lsr & UART_LSR_DR) &&
> + (!(s->fcr & UART_FCR_FE) ||
> + s->recv_fifo.count >= s->recv_fifo.itl)) {
> + tmp_iir = UART_IIR_RDI;
> } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) {
> tmp_iir = UART_IIR_THRI;
> } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA)) {
>
> Signed-off-by: Juergen Lock <nox@jelal.kn-bremen.de>
Yep, that does make sense!
Acked-by: Jan Kiszka <jan.kiszka@web.de>
But I also but Stefano on CC as he introduced the logic above.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2009-09-12 17:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 21:35 [Qemu-devel] qemu serial: lost tx irqs (affectig FreeBSD's new uart(4) driver) Juergen Lock
2009-09-12 11:20 ` [Qemu-devel] " Olivier Cochard-Labbé
2009-09-12 12:26 ` Jan Kiszka
2009-09-12 16:52 ` Juergen Lock
2009-09-12 17:00 ` Jan Kiszka [this message]
2009-09-14 16:59 ` Stefano Stabellini
2009-09-16 19:01 ` Aurelien Jarno
2009-09-23 18:47 ` Juergen Lock
2009-09-24 16:20 ` Aurelien Jarno
2009-09-24 21:26 ` Juergen Lock
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=4AABD3C9.7050900@web.de \
--to=jan.kiszka@web.de \
--cc=freebsd-current@FreeBSD.org \
--cc=nox@jelal.kn-bremen.de \
--cc=olivier@cochard.me \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).