Assuming someone else called the IRQ

Assuming someone else called the IRQ

[Alistair John Strachan]

Hi,

Every kernel in the 2.6 serious so far has exhibited the same problem; after 
some time of running my desktop system, I get:

Assuming someone else called the IRQ

Spamming to the kernel log. Any idea what's causing this or how I can work out 
which driver has the bug? (I suspect yenta_socket, it didn't happen prior to 
me buying a PCI -> PCMCIA cardbus adaptor).

[alistair] 18:04 [~] uname -r
2.6.7

[alistair] 18:06 [~] cat /proc/interrupts
           CPU0
  0:  250894252          XT-PIC  timer
  1:     176607    IO-APIC-edge  i8042
  8:          1    IO-APIC-edge  rtc
  9:          0   IO-APIC-level  acpi
 14:     154556    IO-APIC-edge  ide0
 15:    1427469    IO-APIC-edge  ide1
 16:          4   IO-APIC-level  bttv0
 17:    1050146   IO-APIC-level  ide2, ide3
 18:    1397064   IO-APIC-level  EMU10K1
 19:    8748235   IO-APIC-level  ohci1394, yenta, eth0
 20:          2   IO-APIC-level  ehci_hcd
 21:          3   IO-APIC-level  ohci_hcd, ohci1394
 22:    1218068   IO-APIC-level  ohci_hcd
NMI:          0
LOC:  250913490
ERR:          1
MIS:       3996

Although I have an nvidia video card in the system, the module was not loaded 
and X was not started, so I find it unlikely that this could be to blame. The 
video card would share IRQ 19 as well, if the driver was loaded.

[alistair] 18:06 [~] uptime
 18:07:35 up 2 days, 21:41,  2 users,  load average: 0.13, 0.35, 0.26

Any suggestions would be very helpful.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:    CS/AI Undergraduate
contact:    1F2 55 South Clerk Street,
            Edinburgh. EH8 9PP.

Re: Assuming someone else called the IRQ

[Russell King]

On Sat, Jun 26, 2004 at 06:08:31PM +0100, Alistair John Strachan wrote:
> Every kernel in the 2.6 serious so far has exhibited the same problem; after 
> some time of running my desktop system, I get:
> 
> Assuming someone else called the IRQ
>...
>  19:    8748235   IO-APIC-level  ohci1394, yenta, eth0

You don't say what eth0 is.  At a guess, it's a prism54 card, because the
only place I find that message in the kernel is in the prism54 driver:

drivers/net/wireless/prism54/islpci_dev.c:
	printk(KERN_DEBUG "Assuming someone else called the IRQ\n");

I'd imagine that the OHCI1394 generates a fair number of interrupts,
so... this highlights the problem of leaving debugging printk's,
even at KERN_DEBUG level in a driver interrupt path.

At a guess, Luis R. Rodriguez may be the maintainer for prism54,
so...

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA      - http://pcmcia.arm.linux.org.uk/
                 2.6 Serial core

Re: Assuming someone else called the IRQ

[Alistair John Strachan]

On Saturday 26 June 2004 18:15, Russell King wrote:
> On Sat, Jun 26, 2004 at 06:08:31PM +0100, Alistair John Strachan wrote:
> > Every kernel in the 2.6 serious so far has exhibited the same problem;
> > after some time of running my desktop system, I get:
> >
> > Assuming someone else called the IRQ
> >...
> >  19:    8748235   IO-APIC-level  ohci1394, yenta, eth0
>
> You don't say what eth0 is.  At a guess, it's a prism54 card, because the
> only place I find that message in the kernel is in the prism54 driver:
>
> drivers/net/wireless/prism54/islpci_dev.c:
> 	printk(KERN_DEBUG "Assuming someone else called the IRQ\n");
>

Yes.

> I'd imagine that the OHCI1394 generates a fair number of interrupts,
> so... this highlights the problem of leaving debugging printk's,
> even at KERN_DEBUG level in a driver interrupt path.

I would agree.

>
> At a guess, Luis R. Rodriguez may be the maintainer for prism54,
> so...

Luis, could you please look into removing this message from the sources. It 
causes my kernel ring buffer to be wiped fairly quickly, which is annoying 
for debugging development kernels.

[OT] Thanks for the reply Russell. Any chance you could look over the BIOS 
workaround on bugzilla while we're discussing PCMCIA? I put a patch on there 
that's probably a load of nonsense, and we still haven't got your opinion on 
the matter..

http://bugzilla.kernel.org/show_bug.cgi?id=1840

It affects very few people, but it's a safe enough workaround as I'm using it 
successfully as I write this.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:    CS/AI Undergraduate
contact:    1F2 55 South Clerk Street,
            Edinburgh. EH8 9PP.

Re: Assuming someone else called the IRQ

[Luis R. Rodriguez]

On Sat, Jun 26, 2004 at 06:39:39PM +0100, Alistair John Strachan wrote:
> On Saturday 26 June 2004 18:15, Russell King wrote:
> > On Sat, Jun 26, 2004 at 06:08:31PM +0100, Alistair John Strachan wrote:
> > drivers/net/wireless/prism54/islpci_dev.c:
> > 	printk(KERN_DEBUG "Assuming someone else called the IRQ\n");
> 
> Luis, could you please look into removing this message from the sources. It 
> causes my kernel ring buffer to be wiped fairly quickly, which is annoying 
> for debugging development kernels.

Will do on my next patch, next time just e-mail netdev, cc prism54-devel. 

	Luis
-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Re: Assuming someone else called the IRQ

[Grzegorz Kulewski]

On Sat, 26 Jun 2004, Alistair John Strachan wrote:

> Hi,
> 
> Every kernel in the 2.6 serious so far has exhibited the same problem; after 
> some time of running my desktop system, I get:
> 
> Assuming someone else called the IRQ

Maybe it is just some debug that can be safely ignored and removed from 
source? If two or more devices share an IRQ this is normal that when IRQ  
happens all of these drivers' IRQ routine is called. So maybe one of the 
drivers checks that this is not its device and prints this debug?


>  19:    8748235   IO-APIC-level  ohci1394, yenta, eth0

Maybe you are using eth0 and yenta is printing this debug...
Do you think that assigning the same IRQ for eth0 and yenta is good idea?  
Some network cards seem to raise _many_ IRQs...

Try to grep kernel source for this string and ask the maintainer for the 
driver that produces this message.

Hope this will help a little.


Grzegorz Kulewski

Re: Assuming someone else called the IRQ

[Alistair John Strachan]

On Saturday 26 June 2004 18:20, you wrote:
> On Sat, 26 Jun 2004, Alistair John Strachan wrote:
> > Hi,
> >
> > Every kernel in the 2.6 serious so far has exhibited the same problem;
> > after some time of running my desktop system, I get:
> >
> > Assuming someone else called the IRQ
>
> Maybe it is just some debug that can be safely ignored and removed from
> source? If two or more devices share an IRQ this is normal that when IRQ
> happens all of these drivers' IRQ routine is called. So maybe one of the
> drivers checks that this is not its device and prints this debug?

Yes, this sounds about right. It's the prism54 driver, as Russell identified 
in another reply.

>
> >  19:    8748235   IO-APIC-level  ohci1394, yenta, eth0
>
> Maybe you are using eth0 and yenta is printing this debug...
> Do you think that assigning the same IRQ for eth0 and yenta is good idea?
> Some network cards seem to raise _many_ IRQs...
>

Since the card is a PCMCIA prism3 card in a cardbus adaptor, any interrupt 
sent to yenta will be destined for the eth0 wireless card. It's not really a 
problem, I was just putting the driver under duress because I had the 
firewire controller heavily loaded.

Unfortunately these nForce2 boards crammed full of on-board hardware typically 
assign at least firewire and the AGP slot IRQ 19, and the PCI slot I've got 
the cardbus adaptor in is also sharing this IRQ line. I can't really do 
anything about it, I'm afraid to say.

Thanks for the reply Grzegorz.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:    CS/AI Undergraduate
contact:    1F2 55 South Clerk Street,
            Edinburgh. EH8 9PP.

Assuming someone else called the IRQ

[Margit Schubert-While]

It's fixed in 2.6.7-bk's.

Margit