cgd@netbsd.org (Chris G. Demetriou) writes:

> 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. 

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. 

Of course, if *none* of us have any idea what level things can come
in at and when (because it's all undocmented PALcode magic, for
example), then we should err on the side of caution and boost the IPL
in the interrupt handler.

        - Nathan