handling flow control for console device

handling flow control for console device

[Kittlitz, Edward (Ned)]

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

Re: handling flow control for console device

[Govindraj]

On Wed, Apr 21, 2010 at 12:38 AM, Kittlitz, Edward (Ned)
<ned.kittlitz@alcatel-lucent.com> wrote:
> 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.
>

During boot up most of tty drivers will be using tty_std_termios settings
when we do an uart_register_driver, init_termios will be set to tty_std_termios.

And looking into tty_std_termios we have

 .c_iflag = ICRNL | IXON,

here IXON is enabled by default.

tty_std_termios ---> "drivers/char/tty_io.c"

---
Regards,
Govindraj.R
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html