Losing interrupts?

[pri=-10 Stuart Lynne]

In article <591 at cimcor.mn.org> mike at cimcor.mn.org (Michael Grenier) writes:
>From article <Oct.3.14.16.01.1988.28689 at athos.rutgers.edu>, by hedrick at athos.rutgers.edu (Charles Hedrick):

>A better solution would be to simply put the character into a buffer 
>and return out of the interrupt routine. Then the trick becomes "How
>do we get the characters through the line disipline routines?". One
>method might be to steal an idea that was presented in the book
>"The UNIX Papers" where polling was used in the device drivers. A

>with interrupts turned on. To improve processing time, one could
>allow reads and writes in raw mode to be passed directly to the buffers
>bypassing the line disipline routines altogether. (This assumes

Not really required, the line disciplines are not to bad when it comes to
raw I/O. 

>programs like UUCP and ZMODEM run with the serial line in RAW mode).

Uucp does, zmodem doesn't.


This *is* essentially what SCO is already doing. They have built in support
for a poll routine in a driver which is called every clock tick. Their
interrupt routines for the serial driver are at SPL7 and the clock tick is
SPL6. The serial interrupts operate out of buffers which are filled/emptied
by the poll routine.

>I'm no device driver expert but I think the process can be made to 
>wait at a priority less than PZERO so it will be the next process to run
>every tick or so...we don't want an undue latency time for people
>running terminals on the serial lines.

By using the poll routine (or equivalent using timeout() with other Unix's)
you don't have to worry about running as a user process with the other
attendant issues you mention. You are effectively still running as an
interrupt routine, the trick is to get the clock running at a lower spl
level than serial interrupt. We are not too worried about general overhead
as much as we are worried about leaving lot's of cpu cycles available at
SPL7. In other words when a serial interrupt arrives, there is never a
period of more than one or two hundred micro-seconds before we run the
interrupt service routine.

Of course there are some bugs to be worked out but it does work fairly well.
On problem under SCO 386 is that all of the line discipline routines (e.g.
canon()) protect the tty structure at SPL5. Unfortunately the poll routines
come in at SPL6! There are a couple of small windows where some important
information can get lost and the port will stop functioning until closed and
re-opened. SCO has extra code in their poll routines to compensate for this
problem.

>I would be happy to write the above mentioned driver (to include
>support for the 16550 UARTS sitting here) if someone could explan
>to me what all of the fields in the linesw structure (in sys/conf.h)
>and tty structure (in sys/tty.h) are.

Already done. I'm finishing up the non-polling version today for both SCO
and SysV on the 386. 

Hope to have polling versions tested by next week...  it's working but the 
SPL5 problem is bitch. I've got to ensure that I've found all of the problem
area's.

Actually with the 16550's you don't quite need to go to a polling scheme, 
but with the 16450's it's the only way to guarrantee you don't loose
interrupts.

-- 
Stuart.Lynne at wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl     Vancouver,BC,604-937-7532