wbsd: IRQ handler type mismatch

wbsd: IRQ handler type mismatch

[Robert Hancock]

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 hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: wbsd: IRQ handler type mismatch

[Pierre Ossman]

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

[PATCH] kernel: shut up the IRQ mismatch messages (Re: wbsd: IRQ handler type mismatch)

[Alan]

On Mon, 05 Feb 2007 21:16:59 -0600
Robert Hancock <hancockr@shaw.ca> 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 <alan@redhat.com>

--- 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;
 }

Re: [PATCH] kernel: shut up the IRQ mismatch messages (Re: wbsd: IRQ handler type mismatch)

[Andrew Morton]

On Tue, 6 Feb 2007 11:30:23 +0000
Alan <alan@lxorguk.ukuu.org.uk> wrote:

> On Mon, 05 Feb 2007 21:16:59 -0600
> Robert Hancock <hancockr@shaw.ca> 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 <alan@redhat.com>
> 
> --- 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?

Re: [PATCH] kernel: shut up the IRQ mismatch messages (Re: wbsd: IRQ handler type mismatch)

[Alan]

> > Signed-off-by: Alan Cox <alan@redhat.com>
> > 
> > --- 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