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

> 
> > > I am willing to try the 'unsupported' com driver to see if it fixes this
> > > problem; all I need is that address...
> > 
> > Note that at some point (hopefully soon) this is going to find its way
> > into the post-release branch.
> 
> Has anyone investigated the real cause of the com problems?  I'm still afraid
> that something is keeping the interrupts disabled for too long and this
> causes loss of data in the com driver _and_ in some Ethernet drivers on slower
> machines.

The cause is obvious and quite simple, actually.  Because comintr()
currently runs at spltty(), it must also be blocked by splimp() (more
specifically, by the SLIP and PPP drivers, which run at splimp()).
There are a number of places where splimp() is held for longer than
the com driver can deal with (especially if you use `options
DIAGNOSTIC', SLIP or PPP, or multiple active ports).

There are really only two solutions to this: 1) redesign the interrupt
handling system to get rid of spl*(), or 2) arrange to run comintr()
outside of spltty().  (It's possible to shorten the windows where
splimp() is held, but if you take this approach you'll rapidly hit the
diminishing returns point.  It would be useful to do some analysis
here, though.)  The latter, being just a wee bit less drastic and
being supported by considerable prior art, is what I discussed with
Frank.  From what I've been told, it appears that this alleviates the
problem.

(There have been a few previous projects in this area, including a
port of Bruce Evans's `sio' driver, and a completely new driver by
Bill Wells, but none of these resulted in a version that we could
`ship'.)