The patch titled
Debug handling of early spurious interrupts
has been removed from the -mm tree. Its filename was
debug-handling-of-early-spurious-interrupts.patch
This patch was dropped because it isn't in the present -mm lineup
------------------------------------------------------
Subject: Debug handling of early spurious interrupts
From: Fernando Luis Vazquez Cao <fernando@xxxxxxxxxxxxx>
With the advent of kdump it is possible that device drivers receive
interrupts generated in the context of a previous kernel. Ideally
quiescing the underlying devices should suffice but not all drivers do
this, either because it is not possible or because they did not contemplate
this case. Thus drivers ought to be able to handle interrupts coming in as
soon as the interrupt handler is registered.
Signed-off-by: Fernando Luis Vazquez Cao <fernando@xxxxxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxx>
Cc: David Woodhouse <dwmw2@xxxxxxxxxxxxx>
Cc: Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
Cc: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
Cc: Vivek Goyal <vgoyal@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
kernel/irq/manage.c | 39 +++++++++++++++++++++++++--------------
1 files changed, 25 insertions(+), 14 deletions(-)
diff -puN kernel/irq/manage.c~debug-handling-of-early-spurious-interrupts kernel/irq/manage.c
--- a/kernel/irq/manage.c~debug-handling-of-early-spurious-interrupts
+++ a/kernel/irq/manage.c
@@ -533,21 +533,32 @@ int request_irq(unsigned int irq, irq_ha
select_smp_affinity(irq);
- if (irqflags & IRQF_SHARED) {
- /*
- * It's a shared IRQ -- the driver ought to be prepared for it
- * to happen immediately, so let's make sure....
- * We do this before actually registering it, to make sure that
- * a 'real' IRQ doesn't run in parallel with our fake
- */
- if (irqflags & IRQF_DISABLED) {
- unsigned long flags;
+ /*
+ * With the advent of kdump it possible that device drivers receive
+ * interrupts generated in the context of a previous kernel. Ideally
+ * quiescing the underlying devices should suffice but not all drivers
+ * do this, either because it is not possible or because they did not
+ * contemplate this case. Thus drivers ought to be able to handle
+ * interrupts coming in as soon as the interrupt handler is registered.
+ *
+ * Besides, if it is a shared IRQ the driver ought to be prepared for
+ * it to happen immediately too.
+ *
+ * We do this before actually registering it, to make sure that
+ * a 'real' IRQ doesn't run in parallel with our fake.
+ */
+ if (irqflags & IRQF_DISABLED) {
+ unsigned long flags;
- local_irq_save(flags);
- handler(irq, dev_id);
- local_irq_restore(flags);
- } else
- handler(irq, dev_id);
+ local_irq_save(flags);
+ retval = handler(irq, dev_id);
+ local_irq_restore(flags);
+ } else
+ retval = handler(irq, dev_id);
+ if (retval == IRQ_HANDLED) {
+ printk(KERN_WARNING
+ "%s (IRQ %d) handled a spurious interrupt\n",
+ devname, irq);
}
retval = setup_irq(irq, action);
_
Patches currently in -mm which might be from fernando@xxxxxxxxxxxxx are
fix-config_debug_shirq-trigger-on-free_irq.patch
-
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
