Hello friends,
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
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
---
arch/sparc/include/asm/hardirq_64.h | 2 +-
arch/sparc/kernel/irq_64.c | 5 -----
2 files changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/sparc/include/asm/hardirq_64.h b/arch/sparc/include/asm/hardirq_64.h
index 75b92bfe04b5..874151f520de 100644
--- a/arch/sparc/include/asm/hardirq_64.h
+++ b/arch/sparc/include/asm/hardirq_64.h
@@ -14,6 +14,6 @@
#define local_softirq_pending_ref \
__cpu_data.__softirq_pending
-void ack_bad_irq(unsigned int irq);
+#define ack_bad_irq(irq)
#endif /* !(__SPARC64_HARDIRQ_H) */
diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index 3ec9f1402aad..ea2a52f7fe53 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/irq_64.c
@@ -284,11 +284,6 @@ static unsigned int sysino_exists(u32 devhandle, unsigned int devino)
return irq;
}
-void ack_bad_irq(unsigned int irq)
-{
- pr_crit("BAD IRQ ack %d\n", irq);
-}
-
void irq_install_pre_handler(int irq,
void (*func)(unsigned int, void *, void *),
void *arg1, void *arg2)
--
2.11.0
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
---
arch/parisc/include/asm/hardirq.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/parisc/include/asm/hardirq.h b/arch/parisc/include/asm/hardirq.h
index fad29aa6f45f..78b581f00bb3 100644
--- a/arch/parisc/include/asm/hardirq.h
+++ b/arch/parisc/include/asm/hardirq.h
@@ -34,6 +34,6 @@ DECLARE_PER_CPU_SHARED_ALIGNED(irq_cpustat_t, irq_stat);
#define __ARCH_IRQ_STAT
#define inc_irq_stat(member) this_cpu_inc(irq_stat.member)
#define __inc_irq_stat(member) __this_cpu_inc(irq_stat.member)
-#define ack_bad_irq(irq) WARN(1, "unexpected IRQ trap at vector %02x\n", irq)
+#define ack_bad_irq(irq)
#endif /* _PARISC_HARDIRQ_H */
--
2.11.0
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o "0x" prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
---
arch/ia64/include/asm/hardirq.h | 2 +-
arch/ia64/kernel/irq.c | 9 ---------
2 files changed, 1 insertion(+), 10 deletions(-)
diff --git a/arch/ia64/include/asm/hardirq.h b/arch/ia64/include/asm/hardirq.h
index ccde7c2ba00f..dddaafaf84e0 100644
--- a/arch/ia64/include/asm/hardirq.h
+++ b/arch/ia64/include/asm/hardirq.h
@@ -22,6 +22,6 @@
extern void __iomem *ipi_base_addr;
-void ack_bad_irq(unsigned int irq);
+#define ack_bad_irq(irq)
#endif /* _ASM_IA64_HARDIRQ_H */
diff --git a/arch/ia64/kernel/irq.c b/arch/ia64/kernel/irq.c
index ecef17c7c35b..1365c7cf2095 100644
--- a/arch/ia64/kernel/irq.c
+++ b/arch/ia64/kernel/irq.c
@@ -28,15 +28,6 @@
#include <asm/xtp.h>
/*
- * 'what should we do if we get a hw irq event on an illegal vector'.
- * each architecture has to answer this themselves.
- */
-void ack_bad_irq(unsigned int irq)
-{
- printk(KERN_ERR "Unexpected irq vector 0x%x on CPU %u!\n", irq, smp_processor_id());
-}
-
-/*
* Interrupt statistics:
*/
--
2.11.0
The warning in ack_bad_irq() is misleading in several ways:
* the term "vector" isn't quite correct
* the printing format isn't consistent across the archs: some print decimal,
some hex, some hex w/o 0x prefix.
* the printed linux irq isn't meaningful in all cases - we actually would
want it to print the hw irq.
Since all call sites already print out more detailed and correct information,
we just don't need to duplicate this in each single arch. So just drop it.
Signed-off-by: Enrico Weigelt, metux IT consult <[email protected]>
---
arch/mips/include/asm/hardirq.h | 3 +--
arch/mips/kernel/irq.c | 9 ---------
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/mips/include/asm/hardirq.h b/arch/mips/include/asm/hardirq.h
index c977a86c2c65..75444120e6cb 100644
--- a/arch/mips/include/asm/hardirq.h
+++ b/arch/mips/include/asm/hardirq.h
@@ -10,8 +10,7 @@
#ifndef _ASM_HARDIRQ_H
#define _ASM_HARDIRQ_H
-extern void ack_bad_irq(unsigned int irq);
-#define ack_bad_irq ack_bad_irq
+#define ack_bad_irq(irq)
#include <asm-generic/hardirq.h>
diff --git a/arch/mips/kernel/irq.c b/arch/mips/kernel/irq.c
index 85b6c60f285d..c98be305fab6 100644
--- a/arch/mips/kernel/irq.c
+++ b/arch/mips/kernel/irq.c
@@ -27,15 +27,6 @@
void *irq_stack[NR_CPUS];
-/*
- * 'what should we do if we get a hw irq event on an illegal vector'.
- * each architecture has to answer this themselves.
- */
-void ack_bad_irq(unsigned int irq)
-{
- printk("unexpected IRQ # %d\n", irq);
-}
-
atomic_t irq_err_count;
int arch_show_interrupts(struct seq_file *p, int prec)
--
2.11.0