Losing interrupts?

[pri=-10 Stuart Lynne]

In article <Oct.3.14.16.01.1988.28689 at athos.rutgers.edu> hedrick at athos.rutgers.edu (Charles Hedrick) writes:
>Microport to fix it.  I've recently been working on Minix a lot to get
>serial I/O to work there.  The fixes were in general not to the RS232
>driver, but throughout the kernel to keep down the size of locked code
>segments.  Also some adjustment of buffer sizes, again not at the
>driver level.  I would expect something similar in Unix.  Microport
>may be unable/unwilling to make changes throughout the ATT-maintained
>portion of the kernel.  Everybody keeps yelling about the serial
>device drivers as if the problem could be fixed there.  I really doubt
>it.

I apologize for not making my original comments a little more clear. Yes
this is exactly the problem. You can't just stick a better serial driver in
without changing other things in the kernel as well.

For example one of the basic differences between SCO 386 and the SysV 386 
products is the priority of the interrupts.

	SCO			SysV
  SPL7	Serial		SPL7	Clock
  SPL6	Clock		SPLTTY	Serial

SysV allows the clock interrupt to take over the machine at a higher
priority level than (for example) the serial interrupts.

SCO places the Serial interrupts at the top allowing them to take priority
over virtually everything else in the system.

Which one do you think will loose more serial interrupts (i.e. they both do
but the numbers vary greatly)?

SCO also has some other tricks in the serial driver interrupt handler such
as not doing the standard input process there, but doing it from a poll
routine at the clock interrupt priority level; again allowing receiving
chars to take precedence over processing them.


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