Hi Peter/George: I think this case is not handled. During xmit, say, few bytes are pulled out of recv FIFO and are sitting in tty_buffer. Since IIR is cleared, those bytes could end up staying in tty_buffer till next byte coming in is read from serial8250_rx_chars() and tty_flip_buffer_push() is called. Am I missing something? thanks. On Tue, Apr 28, 2015 at 10:42 AM, George Spelvin <linux@xxxxxxxxxxx> wrote: >>> + help >>> + If you say 'y' here, 8250 driver will check and read from input FIFO during >>> + transmission. This can avoid input buffer overrun by reading from receive >>> + FIFO while waiting for transmitter to be empty. Note that this has no effect >>> + on sysrq handling i.e., if transmitter is busy during sysrq handling, buffer >>> + overrun is still possible. > >> If this has "no effect", then why would anyone ever not want this >> option? And if so, then this shouldn't be an option at all, but rather >> a fix so that everyone can use it. > > The wording could be improved, but the option only changes non-SysRq > serial console output. Such output is done by polling the 8250, and > the patch changes the polling loop to accept input during that time, > so serial input remains reliable. > > Serial console output triggered by a SysRq (which is console *input*) > is a special case: during such output, the 8250 is *not* polled to > avoid re-entrancy problems. > > > (The real-world use case I see is two headless machines with > cross-connected serial consoles, so each is logging the other's serial > console for debugging purposes. It would be possible to remove the > limitation by deferring SysRqs received during another SysRq, but that's > more code and doesn't seem worth it; the use case is machine-generated > input, and SysRq is normally human-generated.) > > > As for your question, me, I think it would be fine to enable > unconditionally. But Peter Hurley wanted a CONFIG_ knob. -- 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
