On 05/01/2015 09:22 AM, George Spelvin wrote: >> Both printk()'s ignore CTS, so output regardless. > > Which is what I said: >>> Either they ignore handshaking during the printk, or deadlock. > > The point is not what Linux does, but that switching off RTS for the > duration doesn't actually solve anything. Except for it does, in the real use case presented (if the console were wired up, that is). > Saying "I might disable RTS for many seconds, but you'e not allowed > to disable CTS for more than 10 ms" is just throwing the problem over > the fence to whoever's listening. Again, CTS is not polled, so it's actually irrelevant what state the remote has set for CTS; the console printk() ignores it. So the sentence above only reads, "I might disable RTS for any length of time because, of course, the tty may not even be open so no one may be listening." But let's back up and look at this from a system perspective. Incoming rx over this port is just one of a long list of interrupts not being serviced during a printk(). What about all the other serial ports that aren't being serviced? Are we not concerned about those overruns? What about all the other system devices that aren't seeing their interrupts serviced either? Regards, Peter Hurley -- 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
