On Fri, 17 Nov 2000, Andrew Gallatin wrote:
> [fxp isa irq pending but never occurs]
> I then wrote a hack which sends an eoi. If I call my hack from ddb
> and send an eoi for irq10, everything goes back to normal and the
> network interface is back.
> So, is it a race in the interrupt code, or is it something about how
> the code is structured?
> On the alpha at least, we get the irq, mask the irq and set the
> ithread runnable. When the (isa) ithread runs, it calls the interrupt
> handler and then sends an eoi. The interrupt is then unmasked.
> I've peeked at the linux code and noticed that they do things
> differently. They first mask the interrupt, and then send the eoi
> immediately -- before the handler runs. They then run the handler
> and unmask the interrupt. The seem to do this both on i386 and
FreeBSD does the same thing on i386's as Linux, except for fast
interrupts it delays the EOI until the handler returns so that the
handler gets called as soon as possible.
> Does anybody have any ideas about this? Does something bad
> happen if you don't send an eoi in a reasonable amount of time?
Delayed EOIs work normally, but lower priority interrupts (according
to the ICU's priority scheme) are masked until the EIO is sent. This
is bad mainly because the ICU's priority scheme is different from
FreeBSD's priority scheme.
Possible causes of the problem:
1) isa_handle_intr() claims to send specific EOIs (0x30 | irq) but
actually sends non-specific ones (0x20 | garbage). Since interrupts
may be handled in non-LIFO order, this results in EOIs being sent
for the wrong interrupts. I think this just randomizes the
brokenness caused by delaying sending of EOIs. I can't see how it
would result in an EOI being lost -- the right number of EOIs will
have been sent after all handlers have returned.
2) Insufficient locking for ICU accesses. Again, I can't see how this
would affect EOIs. On i386's, some accesses are locked implicitly
3) Enabling interrupts (and unlocking the ICU) before sending EOI seems
to just make things more complicated. It requires the specific EOIs
On alphas, interrupts aren't masked in the ICU while they are handled
(the disable/enable args in the call to alpha_setup_intr() in
isa_setup_intr() are NULL ...). They are masked by some combination
of the CPU and ICU priorities.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message