Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=3f0504471536a2b6978b9a99ed1c222950fff07a
Commit: 3f0504471536a2b6978b9a99ed1c222950fff07a
Parent: a304e1b82808904c561b7b149b467e338c53fcce
Author: Alan Cox <[EMAIL PROTECTED]>
AuthorDate: Mon Feb 12 00:52:04 2007 -0800
Committer: Linus Torvalds <[EMAIL PROTECTED]>
CommitDate: Mon Feb 12 09:48:28 2007 -0800
[PATCH] kernel: shut up the IRQ mismatch messages
The problem is various drivers legally validly and sensibly try to claim
IRQs but the kernel insists on vomiting forth a giant irrelevant debugging
spew when the types clash.
Edit kernel/irq/manage.c go down to mismatch: in setup_irq() and ifdef out
the if clause that checks for mismatches. It'll then just do the right
thing and work sanely.
For the current -mm kernel this will do the trick (and moves it into shared
irq debugging as in debug mode the info spew is useful). I've had a
variant of this in my private tree for some time as I got fed up on the
mess on boxes where old legacy IRQs get reused.
Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Cc: Arjan van de Ven <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: David Woodhouse <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
kernel/irq/manage.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 400b12a..7c85d69 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -328,12 +328,14 @@ int setup_irq(unsigned int irq, struct irqaction *new)
return 0;
mismatch:
+#ifdef CONFIG_DEBUG_SHIRQ
if (!(new->flags & IRQF_PROBE_SHARED)) {
printk(KERN_ERR "IRQ handler type mismatch for IRQ %d\n", irq);
if (old_name)
printk(KERN_ERR "current handler: %s\n", old_name);
dump_stack();
}
+#endif
spin_unlock_irqrestore(&desc->lock, flags);
return -EBUSY;
}
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
