I'm seeing this on bootup on my laptop with recent kernels (currently
2.6.20-rc6-mm3):
Floppy drive(s): fd0 is 1.44M
IRQ handler type mismatch for IRQ 6
current handler: wbsd
[<c0451fe7>] setup_irq+0x194/0x1ac
[<e0ad7189>] floppy_hardint+0x0/0xc0 [floppy]
[<c045207b>] request_irq+0x7c/0x98
[<e0a5c67c>] init_module+0x546/0xe15 [floppy]
[<c05ffe85>] _spin_unlock_irq+0x5/0x7
[<c0442410>] __link_module+0x0/0x10
[<c0442410>] __link_module+0x0/0x10
[<c0443d6c>] sys_init_module+0x1781/0x18c8
[<c04dbf10>] blk_init_queue+0x0/0x8
[<c04734f6>] vfs_read+0xa6/0x152
[<c0404e26>] sysenter_past_esp+0x5f/0x85
[<c0600000>] error_code+0x68/0x84
=======================
floppy0: Unable to grab IRQ6 for the floppy driver
It looks like wbsd is being loaded first, which being a nice PnP device
sees that IRQ 6 is available and grabs it. Then the we try to load the
floppy module (which is hard-coded to use IRQ 6) which fails because
wbsd already owns IRQ6 (which is fine, there's no floppy controller
anyway). The mismatch is occurring because wbsd passes IRQF_SHARED
whereas floppy doesn't. I assume one of the two is likely wrong. Should
wbsd really be passing IRQF_SHARED here? This is an LPC device which
uses ISA-style edge triggered interrupts, is it safe to try and share an
interrupt with this chip anyway?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [email protected]
Home Page: http://www.roberthancock.com/
Robert Hancock wrote:
>
> It looks like wbsd is being loaded first, which being a nice PnP device
> sees that IRQ 6 is available and grabs it. Then the we try to load the
> floppy module (which is hard-coded to use IRQ 6) which fails because
> wbsd already owns IRQ6 (which is fine, there's no floppy controller
> anyway). The mismatch is occurring because wbsd passes IRQF_SHARED
> whereas floppy doesn't. I assume one of the two is likely wrong. Should
> wbsd really be passing IRQF_SHARED here? This is an LPC device which
> uses ISA-style edge triggered interrupts, is it safe to try and share an
> interrupt with this chip anyway?
>
This is all perfectly valid. The wbsd hw and driver can handle sharing the
interrupt line, while the floppy cannot. If you want to avoid this, then don't
load the floppy driver or assign another irq for wbsd.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
rdesktop, core developer http://www.rdesktop.org
On Mon, 05 Feb 2007 21:16:59 -0600
Robert Hancock <[email protected]> wrote:
> I'm seeing this on bootup on my laptop with recent kernels (currently
> 2.6.20-rc6-mm3):
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]>
--- linux.vanilla-2.6.20-rc6-mm3/kernel/irq/manage.c 2007-01-31 14:20:43.000000000 +0000
+++ linux-2.6.20-rc6-mm3/kernel/irq/manage.c 2007-02-06 11:01:00.796928504 +0000
@@ -372,12 +372,14 @@
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;
}
On Tue, 6 Feb 2007 11:30:23 +0000
Alan <[email protected]> wrote:
> On Mon, 05 Feb 2007 21:16:59 -0600
> Robert Hancock <[email protected]> wrote:
>
> > I'm seeing this on bootup on my laptop with recent kernels (currently
> > 2.6.20-rc6-mm3):
>
> 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]>
>
> --- linux.vanilla-2.6.20-rc6-mm3/kernel/irq/manage.c 2007-01-31 14:20:43.000000000 +0000
> +++ linux-2.6.20-rc6-mm3/kernel/irq/manage.c 2007-02-06 11:01:00.796928504 +0000
> @@ -372,12 +372,14 @@
> 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;
> }
hm, well, it's dependent upon dwmw2's
generate-a-spurious-irq-at-request_irq-time patch. Do we want to merge
that?
> > Signed-off-by: Alan Cox <[email protected]>
> >
> > --- linux.vanilla-2.6.20-rc6-mm3/kernel/irq/manage.c 2007-01-31 14:20:43.000000000 +0000
> > +++ linux-2.6.20-rc6-mm3/kernel/irq/manage.c 2007-02-06 11:01:00.796928504 +0000
> > @@ -372,12 +372,14 @@
> > 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;
> > }
>
> hm, well, it's dependent upon dwmw2's
> generate-a-spurious-irq-at-request_irq-time patch. Do we want to merge
> that?
CONFIG_DEBUG_SHIRQ seemed to be the right configuration option
irrespective of whether we merge Dave's spurious irq tester (which I
think is actually a good test tool)
Alan