d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

ns8250: don't drop IER_TXRDY on bus_grab/ungrab

Browse Source 
It has been observed that some systems are often unable to resume from
ddb after entering with debug.kdb.enter=1. Checking the status further
shows the terminal is blocked waiting in tty_drain(), but it never makes
progress in clearing the output queue, because sc->sc_txbusy is high.

I noticed that when entering polling mode for the debugger, IER_TXRDY is
set in the failure case. Since this bit is never tracked by the softc,
it will not be restored by ns8250_bus_ungrab(). This creates a race in
which a TX interrupt can be lost, creating the hang described above.
Ensuring that this bit is restored is enough to prevent this, and resume
from ddb as expected.

The solution is to track this bit in the sc->ier field, for the same
lifetime that TX interrupts are enabled.

PR:		223917, 240122
Reviewed by:	imp, manu
Tested by:	bz
MFC after:	5 days
Sponsored by:	The FreeBSD Foundation
Differential Revision:	https://reviews.freebsd.org/D29130
This commit is contained in:
Mitchell Horne 2021-03-10 10:57:12 -04:00
parent 953a7d7c61
commit 7e7f7beee7
1 changed files with 4 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
sys/dev/uart/uart_dev_ns8250.c
View File

@ -738,6 +738,7 @@ ns8250_bus_ipend(struct uart_softc *sc)
} else {
if (iir & IIR_TXRDY) {
ipend |= SER_INT_TXIDLE;
ns8250->ier &= ~IER_ETXRDY;
uart_setreg(bas, REG_IER, ns8250->ier);
uart_barrier(bas);
} else
@ -1035,7 +1036,9 @@ ns8250_bus_transmit(struct uart_softc *sc)
uart_setreg(bas, REG_DATA, sc->sc_txbuf[i]);
uart_barrier(bas);
}
uart_setreg(bas, REG_IER, ns8250->ier | IER_ETXRDY);
if (!broken_txfifo)
ns8250->ier |= IER_ETXRDY;
uart_setreg(bas, REG_IER, ns8250->ier);
uart_barrier(bas);
if (broken_txfifo)
ns8250_drain(bas, UART_DRAIN_TRANSMITTER);