On Thu, Jun 15, 2006 at 01:17:06PM -0700, Garrett D'Amore wrote:
> Wouldn't those 4- or 6- (or more!) port cards generally have working
> FIFOs on them?

Sure, but that only helps so much.  At 115200, you're still talking
about 1000 interrupts/sec (you can't just divide by 16) per port, per
direction.  And that's assuming no control signals are being toggled.
On a 386, this added up very quickly.  That's why the "hard" interrupt
routine had the absolute highest priority, even outside splhigh().  It
worked, at the time, before a lot of crap was added in the path.  Also,
even in the mid-90s, people were starting to "overclock" com-like parts
to 230400 and 460800 bps.

Most of the architecture of the driver is based around just getting the
bytes off the chip as fast as possible.  If you ever get overloaded
with interrupts, you can end up (even with a FIFO) in a mode where you
never get more than 16 contiguous bytes -- and at that point pretty
much any protocol (PPP, SLIP, Zmodem, Kermit, whatever) running over
the link is just dead in the water.  So the "hard" interrupt was kept
absolutely minimal (and I came up with some semi-clever things, like
testing all the control bits with a single test), and I added a whole
flow control mechanism around the software FIFO to allow selectively
turning off the interrupt and ensure that we got larger chunks of good
data.  (AFAICT, I was the first person to specifically identify this
livelock condition in serial drivers and design around it.  At the time
we had better serial performance than FreeBSD or the classic SCO "FAS"
driver.  Unfortunately nobody pays attention to these things any more.)