Re: How to disable the transmit FIFO?

[Michael Haardt <michael@moria.de>]

> > I miss a way to disable the transmit FIFO.
>
> From userspace or from within a kernel driver?

>From userspace.

> > UARTs that don't do hardware handshaking in hardware, but use a transmit
> > FIFO, can only be used if the peer can deal with the delayed handshaking
> > response.
> > 
> > If slow peers can not receive at line rate, hardware handshaking will
> > still cause overruns with Linux as sender, because Linux fills the
> > transmit FIFO and transmission continues at worst for 16 characters with
> > a 16550 after CTS was asserted.
> > 
> > So, how can I fix hardware flow control response to the non-delayed
> > behaviour as it worked with a 8250 or 16450 by disabling the transmit
> > FIFO?
>
> So you are saying this used to work and now it doesn't?

It used to work with old non-FIFO UARTs (8250, 16450) and does not work
with the slightly newer FIFO-UARTs (16550 and up, probably excluding
those that can do RTS/CTS flow control in hardware).

A transmitter FIFO on a UART that can not do RTS/CTS flow control in
hardware delays the flow control response by the size of the FIFO.
By the time Linux notices CTS being set, the FIFO is already filled and
the transmitter keeps sending, despite the peer asking to pause.

It is desirable that flow control has minimal delays from seeing CTS
to pausing the flow.  Given a 16550 UART, you have to disable the
transmitter FIFO for that.  One could argue whether the default should
be high throughput (use the FIFO and delay handshaking) or correct flow
control (no FIFO and near instant handshaking).  Most systems default
to the first.

The admin has to know if the peer allows delayed flow control and
configure it for the affected UART ports.  Windows allows exactly that
and the MS knowledge base correctly describes that the FIFO size may
cause data overruns, suggesting to reduce it until the problem goes away.
A binary switch, as offered by BSD, probably suffices, though.

Michael