From 7e7f7beee732810d3afcc83828341ac3e139b5bd Mon Sep 17 00:00:00 2001 From: Mitchell Horne Date: Wed, 10 Mar 2021 10:57:12 -0400 Subject: [PATCH] ns8250: don't drop IER_TXRDY on bus_grab/ungrab 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 --- sys/dev/uart/uart_dev_ns8250.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sys/dev/uart/uart_dev_ns8250.c b/sys/dev/uart/uart_dev_ns8250.c index d920a76ae275..45b4d315c3d5 100644 --- a/sys/dev/uart/uart_dev_ns8250.c +++ b/sys/dev/uart/uart_dev_ns8250.c @@ -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);