Hello friends,
<< reposting, since first queue didn't go through completely, due to mailer problem >>
here's a patch queue for cleaning up the IRQ handling. Inspired by a
discussion we had on a previous patch of mine:
"arch: fix 'unexpected IRQ trap at vector' warnings"
https://www.spinics.net/lists/kernel/msg3763137.html
Turned out that the whole message, as it is right now, doesn't make much
sense at at all - not just incorrect wording, but also not quite useful
information. And the whole ack_bad_irq() thing deserves a cleanup anyways.
So, I've had a closer look and came to these conclusions:
1. The warning message doesn't need to be duplicated in the per architecture
ack_bad_irq() functions. All, but one callers already do their own warning.
Thus just adding a pr_warn() call there, printing out more useful data
like the hardware IRQ number, and dropping all warnings from all the
ack_bad_irq() functions.
2. Many of the ack_bad_irq()'s count up the spurious interrupts - lots of
duplications over the various archs. Some of them using atomic_t, some
just plain ints. Consolidating this by introducing a global counter
with inline'd accessors and doing the upcounting in the (currently 3)
call sites of ack_bad_irq(). After that, step by step changing all
archs to use the new counter.
3. For all but one arch (x86), ack_bad_irq() became a no-op.
On x86, it's just a call to ack_APIC_irq(), in order to prevent lockups
when IRQs missed to be ack'ed on the APIC. Could we perhaps do this in
some better place ? In that case, ack_bad_irq() could easily be removed
entirely.
have fun,
--mtx
