>> + 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
