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.
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
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
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.
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.
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