Re: Common IRQ pitfall results in lockup.

Richard Gooch (rgooch@ras.ucalgary.ca)
Fri, 5 Nov 1999 08:40:51 -0700


Rogier Wolff writes:
> +Then the second driver is unloaded/doesn't need the interrupt
> +anymore. It then tries to free its own interrupt routine, but the
> +kernel frees the first matching interrupt on the IRQ chain for that
> +interrupt. This happens to be the first drivers interrupt
> routine. Now +when some activity happens on the first device, it
> will interrupt, but +the second driver's interrupt routine, still on
> the chain will get +called. It cannot cause the first device to stop
> interrupting, so an +interrupt storm occurs. As soon as interrupts
> are re-enabled, the CPU +is interrupted again. Clients report this
> as a complete lockup.

Something I'd like to see is that request_irq() return an ID (in fact
a pointer to the struct irqaction) that can be used by drivers to free
the IRQ. This would eliminate the search (not a big deal, considering
that each IRQ isn't likely to have lots of drivers on it), and would
look cleaner.

We could use such a change to fix the problem Rogier mentioned: change
free_irq() to take struct irqaction *. It's a bit harsh, as all
drivers would need to be modified, but it would ensure the problem
would be fixed once and for all. The less intrusive option would be to
create free_irqentry() and encourage driver maintainers to upgrade.

What do people think of this idea? If people like it, I might even be
persuaded to do some of the leg-work.

Regards,

Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/