nathanw@MIT.EDU (Nathan J. Williams) writes:
> > > On the Alpha, device interrupts can come in at IPL 3 or
> > > 4; the spl calls that block device interrupts set the IPL to 4. The
> > > ohci interrupt happened to come in at 3, so _s got the value 3 and _su
> > > got 4, even though further ohci interrupts would be blocked. 
> > 
> > OK, so, this points to a bogon in the alpha interrupt code.
> > 
> > If the device interrupts can come in at either 3 or 4 (with the kernel
> > not easily determining which beforehand), then it's the interrupt
> > handler's responsibility to block all both 4 and 3.
> > 
> > i.e. by the time the handler is called, 4 should already be blocked.
> 
> It's only a problem if a device in one splfoo() class can come in at
> 3, and another device (or the same device re-interrupting) at the same
> or lower splfoo() class can come in at 4. 

Right.  If no device can come in at 4, though, splfoo() shouldn't
block 4.  (that's inefficieint.)


> I have N-F-C if this is actually the case. The (to me) more likely
> case of the PALcode universally using only one of 3 or 4 on a given
> box doesn't seem like a problem. 

It's never been clear to me whether it's one value or the other on a
given box, on a given interrupt line, or "other."


cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.