Jukka Marin <jmarin@pyy.jmp.fi> asked:

[ Hope you don't mind me cc'ing port-i386 ]

> 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.

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

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.

Hmmm, I just noticed

#ifdef REORDER_IRQ

in /sys/arch/i386/isa/isa_machdep.c.

You could use this to change the priority order of the IRQs.
But, I seem to remember that using my com port at irq 9 running at 115200 bps
on a null modem cable while find / -print was busy on another ttyv
still produced overflows.

Onno