> I'd vote for changing the return value of the interrupt handlers to
> (int), and return a I_DID_SOME_STUFF flag. That way, if none of the
> interrupt handlers for an IRQ return this flag, the kernel belches out
> "Nobody handled interrupt X", which would quickly grab people's attention.
I like that. That'll cause even more trouble if everybody just defaults
to saying I_DID_SOME_STUFF even if they didn't. The more trouble it
causes, the quicker things will get fixed.
At the moment, I feel that various parts of bottom halves are being
run (especially for PCI devices), that just luckily get away without
causing any trouble except slowing things down. Hard to know without
a thorough review though...
For example look at drivers/atm/ambassador.c
The logic that ends with "definitely for us" doesn't mean it is for
us at all, it means that it's an interrupt on the IRQ it specified
and nothing more (well, I hope that's what it means since I've said
it on lkml :))
> Unfortunately, it would also grab your attention if there really are
> spurious interrupts that you don't care about.
Surely we should know about these and handle them? After all if nothing
handles a non-shared interrupt, the kernel disables the interrupt controller
for that irq.
> At the same time, it would be nice to have a RUN_MY_BOTTOM_HALF_PLEASE
> flag. This would be another way to grab driver writer's attention, since
> the bottom halves would break.
I think that's tangential. In a shared interrupt case, what would know
which bottom half was responsible?
alan@lxorguk.ukuu.org.uk said:
: Now I make two expensive indirect jumps per irq.
But the code is going to be run anyway, and it isn't at interrupt time,
it's at bottom half time.
: Drivers that don't do proper checking get noticed quite fast - as you've
: discovered.
But I've discovered the opposite. I wouldn't have noticed the uhci problem
except that I had some extra debugging enabled in the USB mouse driver
which showed me the problem. If it weren't there, it might not have been
noticed for some time as it doesn't necessarily provoke a problem.
I've also never solved the unhandled PCI interrupt, I just shifted
an arbitrary PCI device from one interrupt to another with setpci
even though I don't know what device it's connected to. That took
me days to figure out.
Paul
-
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/