On Tue, May 20, 1997 at 08:23:46PM +0200, Onno van der Linden wrote:
> > Now the question: Do you think filling up all the 16 bytes at once is a
> > good idea with these dumb UART chips?  Or how would you feel if there was
> > an ioctl to manipulate the Rx FIFO treshold and Tx FIFO use from outside
> > the kernel?  This would help a lot when you're having serial problems with
> > some important hardware.
> 
> My first thought is that creating overflows on the other site by filling
> 16 bytes at once shouldn't be possible. The other side should use a driver
> that uses a buffer of the right size and a well defined threshold to handle
> the extra bytes whenever it has asked the other end to stop transmitting.

Well, this NetBSD machine talks to several os/2 machines and _they_ can't
keep up with the data flow at 38400 bps.  We were getting lots of errors
in zmodem data transfer until I changed the Tx side of NetBSD to fill only
8 bytes of the FIFO.  All overflows were history.

> Of course, it's alway possible to have lots of data `on the line' but
> 16 more bytes should never matter.

True, it shouldn't, but in this case this simple fix solved a serious
problem :)

> It shouldn't be too difficult to create a tool to change all kinds of
> buffer sizes on the fly, although at the moment I'd really like to know
> what other routines / processes are able to block the serial interrupt
> for such a long time to generate overflows.

Yes, this is an important question.  A fast machine (P200) seems to be doing
fine with lots of serial ports under NetBSD 1.2 even - but if a slow 8-bit
CPU can handle 38400 on 7 lines (the Amiga A2232 serial card), any machine
capable of running NetBSD should be able to service at least a few lines
without problems.

  -jm


-- 

                       1503 kHz @ 22:30 EET DST Mon-Fri

                     ---> http://www.jmp.fi/~jmarin/ <---