Date: Fri, 25 Sep 1998 07:54:19 +1000 From: Bruce Evans <bde@zeta.org.au> To: gibbs@plutotech.com, mike@smith.net.au Cc: bde@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: options DPT_LOST_IRQ Message-ID: <199809242154.HAA31021@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>Yes; the FAST_INTR() code basically looks like: >> >>fastintr: <- entry with PSL_I clear, interrupts masked >> call handler <- handler runs with interrupts masked >> sti <- reenable interrupts >> rti > >But why doesn't the PIC record any interrupts that occur while the >CPU has interrupts blocked in its pending mask? Or is this simply >a problem because the I/O APICs on SMP systems work in some other >strange way? PICs only record interrupts when interrupts are acknowleged by the CPU. Interrupts are not acknowledged while the CPU is ignoring them. The problem with shared interrupts that I referred to in previous mail is similar. PICs don't record new interrupts while an interrupt is in service: intr_mux: <- entry with PSL_I set, but interrupts masked in PIC traverse linear list of interrupt handlers: <- interrupts masked in PIC throughout ... check for interrupt on funky device, don't find it ... begin handling interrupt for "slow" device <- interrupt from funky device masked in PIC, ignored ... <- interrupt from funky device goes away finish handling interrupt for "slow" device ... outb... <- unmask interrupt in PIC iret The interrupt for the funky device is never seen. This bug can be worked around by using a circular list and traversing it until no activity has been seen for a full circuit. Some ISA interrupt handlers have to do this with their own interrupts to avoid a variant of the problem. 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?199809242154.HAA31021>