ppc_irq_dispatch_handler and unhandled interrupts

Paul Mackerras paulus at samba.org
Sat Nov 23 09:45:52 EST 2002

Hollis Blanchard writes:

> Here's the failure mode:
> On a 405LP (using ppc405_pic), an irq is becoming unmasked[1] (in
> UIC0_ER). ppc_irq_dispatch_handler sees irq_desc[0].action == NULL, and
> correctly complains of an unhandled interrupt and masks it off. However
> at the end of the same function (label "out"), the irq is unmasked again
> because irq_desc[0].handler == ppc405_pic (irq_desc[0..NR_IRQS] =
> ppc405_pic; see ppc4xx_init_IRQ() ). So the irq is unmasked, occurs
> again, is masked, is unmasked, occurs again...
> The attached patch fixes the problem by checking desc->action as well as
> desc->handler - there is no sense unmasking an interrupt if we already
> know there are no drivers ready to handle it.

This is the wrong fix IMO.  The situation is no different to calling
disable_irq during an interrupt handler, and as the comment says, the
->end() handler has to deal with that.  The problem is that if we
don't have an ->end() handler we unconditionally call the ->enable()
handler, which (correctly) just unconditionally enables the
interrupt.  So the bit of code at the end of ppc_irq_dispatch_handler
should look like this:

	 * The ->end() handler has to deal with interrupts which got
	 * disabled while the handler was running.
	if (irq_desc[irq].handler) {
		if (irq_desc[irq].handler->end)
		else if (irq_desc[irq].handler->enable
			 && !(irq_desc[irq_nr].status

> [1] In my particular case, UIC0_ER is being modified by BIOS when waking

BIOS???  What BIOS?


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc-dev mailing list