Date: Sun, 19 Nov 2000 06:48:18 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.ORG Subject: Re: missing interrupts (was Re: CURRENT is freezing again ...) Message-ID: <Pine.BSF.4.21.0011190449250.502-100000@besplex.bde.org> In-Reply-To: <14869.58648.34403.679348@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > alpha. 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 by sched_lock. 3) Enabling interrupts (and unlocking the ICU) before sending EOI seems to just make things more complicated. It requires the specific EOIs in (1). 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011190449250.502-100000>