Path: utzoo!attcan!uunet!van-bc!sl From: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Newsgroups: comp.unix.microport Subject: Re: Losing interrupts? Message-ID: <1907@van-bc.UUCP> Date: 5 Oct 88 20:22:19 GMT References: <591@cimcor.mn.org> Reply-To: sl@van-bc.UUCP (pri=-10 Stuart Lynne) Organization: Wimsey Associates, Vancouver, BC. Lines: 68 In article <591@cimcor.mn.org> mike@cimcor.mn.org (Michael Grenier) writes: >From article , by hedrick@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@wimsey.bc.ca {ubc-cs,uunet}!van-bc!sl Vancouver,BC,604-937-7532