Commit a54c346f authored by Mitchell Horne's avatar Mitchell Horne
Browse files

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
Sponsored by:	The FreeBSD Foundation

(cherry picked from commit 7e7f7bee)
parent cf0310df
......@@ -735,6 +735,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
......@@ -1032,7 +1033,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);
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment