From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MmRh3-0000rF-2o for qemu-devel@nongnu.org; Sat, 12 Sep 2009 08:27:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MmRgy-0000lg-Ea for qemu-devel@nongnu.org; Sat, 12 Sep 2009 08:27:04 -0400 Received: from [199.232.76.173] (port=50750 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MmRgy-0000lQ-3j for qemu-devel@nongnu.org; Sat, 12 Sep 2009 08:27:00 -0400 Received: from fmmailgate03.web.de ([217.72.192.234]:56230) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MmRgx-0006tp-IJ for qemu-devel@nongnu.org; Sat, 12 Sep 2009 08:26:59 -0400 Message-ID: <4AAB938B.9080004@web.de> Date: Sat, 12 Sep 2009 14:26:51 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <20090911213508.GA97446@triton8.kn-bremen.de> In-Reply-To: <20090911213508.GA97446@triton8.kn-bremen.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig309899C2597520924D81F45D" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: qemu serial: lost tx irqs (affectig FreeBSD's new uart(4) driver) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juergen Lock Cc: Olivier =?iso-8859-1?Q?Cochard-Labb=E9?= , freebsd-current@FreeBSD.org, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig309899C2597520924D81F45D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Juergen Lock wrote: > Hi! >=20 > 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=3D"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, >=20 > Index: qemu/hw/serial.c > @@ -189,7 +188,9 @@ static void serial_update_irq(SerialStat > { > uint8_t tmp_iir =3D UART_IIR_NO_INT; > =20 > - if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)) { > + if ((s->ier & UART_IER_THRI) && s->thr_ipending) { > + tmp_iir =3D UART_IIR_THRI; > + } else if ((s->ier & UART_IER_RLSI) && (s->lsr & UART_LSR_INT_ANY)= ) { > tmp_iir =3D 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 >=3D s->recv_fifo.itl) { > tmp_iir =3D UART_IIR_RDI; > } > - } else if ((s->ier & UART_IER_THRI) && s->thr_ipending) { > - tmp_iir =3D UART_IIR_THRI; > } else if ((s->ier & UART_IER_MSI) && (s->msr & UART_MSR_ANY_DELTA= )) { > tmp_iir =3D UART_IIR_MSI; > } >=20 > ...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. Jan --------------enig309899C2597520924D81F45D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkqrk48ACgkQniDOoMHTA+l5oACaAxp+RmBQopRHs4BUx4cWYrvi DEsAn16MEFIANDli5BQIla0Hop52Ojcu =wNVL -----END PGP SIGNATURE----- --------------enig309899C2597520924D81F45D--