I have made a lot of progress understanding the problem with flow
control. First, I have added flow control to the ring buffer so that
it never overruns if CRTSCTS is set. Instead, it backs up in the rx
fifo and the duart automatically de-assert RTS. This seems to work.  I
can arrange an input stream from another machine (my Sun3) and cat the
relevant tty. When I suspend cat, the RTS light on my rs232 tester
changes colour. Resume cat and the RTS light changes back. So far so
good.

If I cat /dev/tty01 > /dev/null, it chuggs away OK with the RTS light
occasionally flashing. So, the auto RTS really is working and RTS
really does stop the flow from the Sun (which is of course, the other
side of the picture). The trouble is, I still get the occasional fifo
overrun. I have come to the conclusion that this is because the Sun
detects changes in CTS with a status change interrupt which it may not
process quick enough. The scn2681 family doesn't deassert RTS until
the fifo is full *and* it has received the start bit for the next
character. That means the other end has one character time to detect
the CTS before it sends the next character.

[Aside]
The Sun (like most serial drivers) doesn't send the next
character until it gets a tx interrupt so it should be possible to
ensure that the status interrupt can get in, but maybe there is a way
the tx interrupt can happen first. The Sun serial drivers are not a
lot of interest to me now I have and ethernet connection, but the same
thing happens with my modem so it may have the same characteristic.
[End Aside]

So, the demands on the other end detecting CTS are quite severe. I would
guess that that is why Matthias Pfaller does not get any overruns
between his two pc532's. The scn2681 family responds to CTS changes
in hardware.

OK, so that explains why the RTS flow control doesn't always work, but
surely a pc532 can keep up with a Sun 3/50 (about 1/4 the speed) even
without flow control?  There are a couple of problems. One is that for
some reason the scn driver establishes the rx interrupts at
IPL_ZERO. I thought, "wow, there must be some counter intuitive
meaning to IPL_ZERO", but looking at intr_establish, IPL_ZERO is
exactly what one would expect. *All* interrupts which have ever been
intr_established are enabled.  So, I created IPL_RTTY at slightly
higher than IPL_TTY. This is a definite improvement. It could be made
even higher, but I don't think that would help. Here is the real
problem. The scsi driver has to do transfers in one direction (read I
think) with all interrupts disabled. At very high serial baud rates,
it is easy for interrupts to be blocked out for long enough for the
fifo to overrun.

At human typing speeds there is no problem, but for high speed ppp or
slip the scsi interface makes it more or less essential to use
hardware flow control and it seems not all peripherals handle that
well enough. I must remember to make sure I explicitly turn the modem
to hardware flow control in its init string!

Ian