darcy@druid.net (D'Arcy J.M. Cain) wrote on current-users:
[ Subject: Serial port driver ]

I assume this is all about the i386 com driver, which is why
my reply appears on port-i386 instead of current-users.

> What is the latest story on this?  I remember 2 years ago people were
> issuing patches to get around silo overflows and yet I still see them.

'people' most certainly includes me, and when I made my first
patches (based on message from Bill Wells to current-users) I was
able to do 115200 bps on a null modem cable between two 486DX2's
that had 8250s in 'em.

The only time I've seen overflows was receiving termcap.db at 115200 bps
on a null modem while find / -print was running on another virtual console.

If I remember it correctly (Frank ?) it's also possible
to get overflows when
(1) there's a network connection between two machines with lots of traffic
    (e.g. an ftp session) and
(2) at the same time you transfer data at 115200 bps (e.g. termcap.db)
    between these machines.

> Is there something fundamentally different between the way we do serial
> I/O and the way FreeBSD and Linux do it?  Those systems don't have any
> problem with high speed serial transfers as far as I know whatever
> ethernet card they use or if they use IDE drives.  (I recall discussion
> which suggested that these could have a bearing on the problem.)  Why
> do we still have to apologize for our serial performance?

I haven't seen a serial overflow in a long, long time and that's with
two IDE drives.

> I am trying to look at the code but two things stop me.  First of all
> I can't find a good, clear discussion of how the driver interacts with
> the other parts of the system, particularly with the device/terminal
> routines interaction.  I have "The Design and Implementation of the
> 4.4BSD Operating System" but, while it is an excellent book, it lacks
> the detail I am looking for.

The serial driver runs at IPL_SERIAL (see <machine/intr.h> and isa_machdep.c)
which blocks all the other interrupts. The comintr() routine puts the
received data in a ring buffer that is handled at SOFT_SERIAL (a soft
interrupt that is scheduled via a call to setsoftserial()) and quits
as soon as possible.

There was talk of a multi byte ttyinput() routine instead of the single byte
routine we have right now.

One request at the end of all this: if someone still has problems
with overflows on x86 machines can they please give a very accurate
description of the situation (software, hardware and processes that
are running) in which the overflows occur.

Onno van der Linden (onno@simplex.nl)