Fw: Common IRQ pitfall results in lockup.

Stuart MacDonald (stuartm@connecttech.com)
Fri, 5 Nov 1999 12:03:22 -0500

From: Raj, Ashok <ashok.raj@intel.com>
> Another one i would recommend if this is making its way to the base linux
> kernel is that we should ask the irq handlers to return some value so that
> the kernel could know who took this interrupt. so if 2 devices are sharing
> an
> interrupt, and if the kernel calls the first registered handler, and it
knew
> its
> device interrupted, then on returning from the irq handler if we return 1
to
> indicate this interrupt is consumer, we possibly dont need to send this to
> all of the
> registered handlers?

To add to the complexity of the idea; the kernel could even keep a count
for which handler was getting how many interrupts, and keep the list
sorted, so that the most likely handlers get called first. If there was a
serial board and a video board and a data acquisition board, then
you'd have a list like:

handler count
serial 3000
data 250
video 22

So the next interrupt would go to the serial board first, cause it's
most likely to handle it.

I haven't check the source, but since /proc/interrupts keeps a count
for each interrupt, I assume the counting is already being done. It
just needs to be split among the handlers.

Of course, this now raises the question of should /proc/interrupts be
changed to reflect the breakdown among handlers?

...Stu

-
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/