Weird interrupt problem

[Benjamin Herrenschmidt]

>Today this happened to me the second time: All of a sudden, the USB
>mouse stopped working. At the same time this appeared in the syslog:
>
>Aug  7 17:19:57 tibook kernel: Unhandled interrupt 1d, disabled
>
>Plugging the mouse to the other socket worked, but it wouldn't work
>again in the original one. As you can see in the attached
>/proc/interrupts, interrupt 29 (=1d) is unknown. Interestingly,
>interrupt 28 seems to be for the USB socket which stopped working (I
>think it was the same one when the first problem first occured, might be
>coincidence though). Was it somehow rewarded for its 100'000th
>occurence? ;) Seriously, is it possible that the number changed somehow?
>
>
>This wouldn't be all that bad, if the whole system wasn't very sluggish
>afterwards. When it occured the first time, I had CONFIG_TAU enabled in
>the kernel, which Ben said might cause the sluggishness at least. But
>now it's disabled.
>
>
>This is on a TiBook III/667 running 2.4.18-ben0-lotsanicestuff if it
>matters. The first occurence was with 2.4.19-presomething-ben0.
>
>
>Has anyone experienced anything similar?

Really weird. It looks like the openpic is going south. Seriously, looks
like a HW problem, that is the interrupt controller starts giving us
bogus interrupt numbers. Doesn't sound good at all :(

Ideally, when that happens, you could drop into macsbug and peek at
the vector/priority & destination registers for this interrupt source
and tell me what they say. (Hook into the code for the error message
which is in arch/ppc/kernel/irq.c, and call a function you'll write
in open_pic.c that will dump these (to access them, look at what
openpic_enable/disable IRQ does).

It may be some kind of race within the openpic driver when we keep
enabling/disabling the source in ack() and end(). I'm pretty sure
we don't really need them, oh well...

Ben.


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