>>
>> Definitely not the right fix. If the hardware status struct
>> indicates no event is pending, then we return 0 since we
>> didn't "handle" the interrupt.
>
> This is about the fifth report of unhandled interrupts. Against the fifth
> driver which looks to be correct.
>
> So I'd be suspecting the scenario which Alan outlined: the IRQ handler looped
> around, scooped up the interrupt source before the APIC delivered the IRQ.
>
> I'm working on the actual detection code - it tries to filter out the false
> positives.
On thinking about it further, I don't think you will ever be able to write
such code -- whether "interrupt received but no pending work" is an error
or not is a private matter between the driver and its device. All you can
really ask the driver for is "was that interrupt generated by your device?"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/