Subject: Re: USB controller goes nuts on Alpha
To: Nathan J. Williams <nathanw@MIT.EDU>
From: Chris G. Demetriou <firstname.lastname@example.org>
Date: 02/08/2000 13:07:35
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."
Chris Demetriou - email@example.com - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.