Hello, I've been trying to figure out the Linux philosophy on flow control for console devices. We have several situations where flow control can stop bootup or normal operation. For us, it's more important that things keep running; console output has lower priority. I thought there would be some way to forcibly disable flow control for the console. But I can not find any way to do it. In my case, it's XOFF flow control. I have searched multiple online system admin books and also some kernel books, and don't see much discussion of flow control. There's a bit about enabling RTS/CTS flow control in bootargs, but nothing about a big hammer to avoid the problem. Some examples: - I think XOFF can happen while RC scripts are running, and bootup stops. I think that the RC scripts start running without a control terminal, but at some point a script does something that attaches one. *1 I haven't figured outwhere I might be able to put an 'stty -ixon' in the rc processing. I think the problem happens when rc3.d is processed. - login as root can be blocked because login is trying to write a message to the console. e.g. user is logged in on console and has sent XOFF. *2 I have not found a way to force getty to start with -ixon for the console device. *1/*2 neither of these solutions make me totally happy, but they might be good enough. I'd like to be able to fix this in the kernel and/or OS files, and not rely on external equipment configuration. It's hard to control customers. DETAILS: I'm working on embedded system boards using powerpc CPUs and uboot. We have private drivers. bootargs specifies the device: console=ttySCS1,9600 Also, I have an inittab login on this device (not on "console"). Most stty operations do not get to UART_set_termios(), so I can not even put a hack in our driver that would always disable flow control (XOFF and RTS/CTS). We first saw this problem in our lab, on a board with the DB9 connected to a terminal server. The T.S. has large buffers. I believe it will send XOFF if the buffer fills, and it will not send XON until somebody opens a session to the T.S. port. I assume it will send more XOFF characters if it receives more data from the DB9. Thanks for any comments or suggestions, Ned Kittlitz -- 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
