Return to BSD News archive
Newsgroups: comp.os.386bsd.bugs
Path: sserve!newshost.anu.edu.au!munnari.oz.au!metro!ipso!runxtsa!bde
From: bde@runx.oz.au (Bruce Evans)
Subject: Re: Excessive Interrupt Latencies
Message-ID: <1993Mar21.061151.13372@runx.oz.au>
Organization: RUNX Un*x Timeshare. Sydney, Australia.
References: <1993Mar19.221353.14068@netcom.com> <1993Mar20.011150.4650@netcom.com>
Date: Sun, 21 Mar 93 06:11:51 GMT
Lines: 48
In article <1993Mar20.011150.4650@netcom.com> jtk@netcom.com (Jane Valencia) writes:
>thinman@netcom.com (Technically Sweet) writes:
>
>>My experience hacking the at&t unixes for 286 and 386 for the
>>past 6 years has convinced me that emulating the pdp-11 SPL tower
>>is silly.
>
>I'll give a cautious second to this. When I started doing the I/O
>sections of my microkernel I decided to use the interrupt mask of
>the PIC only for purposes of globally enabling interrupts--i.e.,
>when a server registers for an IRQ then that IRQ is enabled, otherwise
>it is left masked at the PIC.
This is more or less what my rewrite of spl*() for 386BSD does. The PIC
is only used to mask currently active interrupts (even this could be
avoided for most devices, by depending on edge-triggered interrupts to
not generate solid stream of interrupts). The original (386BSD, not
PIC) priority scheme is implemented on top of this. When a higher
priority interrupt is received, it is handled immediately. When a lower
priority interrupt is received, it is masked in the PIC and handled
later when splx() or spl0() lowers the priority sufficiently.
>Since the machine-independent parts of my microkernel is written for a
>multiprocessor, I unified the "spl" concept with spinlock mutexing.
>...
>The result is pretty good, at least on an i386. I'm pretty sure these
>techniques would fall apart if I had to take them back to an 11/03, but
I've used similar methods on an 8088. There's not overhead apart from
fiddling with the PIC.
>BTW, if anybody noticed all the stray interupts coming in via the lpt1:
>IRQ vector. Turns out these are caused by the way 386BSD does the EOI
>to the pair of PICs. If you want to see something interesting, mask
>out the IRQ on the first PIC which chains to the second PIC (IRQ4, I think).
IRQ2
>The stray interrupts will stop arriving. Hard to do unless you're
>floppy based, which is what I was at the time. I think there's a directed
>EOI which might fix the problem.
I thought they were from glitches on the IRQ0-6 lines. I may be partly
responsible for the way 386BSD does the pair of EOI's :(. I like to do
things in lexiccal order, ICU1 followed by ICU2 in this case. But the
order ICU2, ICU1 makes more sense. I now use auto-EOI to avoid these
i/o's. auto-EOI is said not to work for the slave (because of the same
timing glitch?) but works fine on my system.
--
Bruce Evans bde@runx.oz.au