The "actually likely to happen in the real world" use case I imagined was servers with cross-connected serial consoles trying to catch each others' panic outputs. And then enabling some debugging. While *usually* not dropping characters is good enough for debugging, it would definitely be nice to not drop data. > I think you may misunderstand what I mean here. > > I don't think rx could overflow while waiting for the transmitter to empty > here: > > 1. the last output char has just been written to the tx fifo by > serial8250_console_char() > 2. this means the tx fifo can have at most 1 char in it right now > 3. the rx fifo was just read at most 1us before the tx fifo was written > 4. so this call to wait_for_xmitr() is only waiting for 1 char to be output > plus how ever much data the shifter can hold, which probably isn't much > How could the rx fifo overflow in the time it takes the xmitr to send > 1-2 chars, especially since the rx fifo was being polled at 1000x oversample > (every 1us for each 1ms tx char)? Yes, this makes lots of sense now. Unless the Rx/Tx speed ratio (something that isn't even poossible on most 8250 variants) exceeds the Rx FIFO size, Rx can't overflow. Tx speed could be decreased by hardware handhsaking, but if you have hardware handshaking that protects the Rx side as well. (Unless you have asymmetrical handshaking, in which case you deserve what you get.) -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
