All,
Not sure if this is the proper fix, but it stops the kernel from
complaining. I saw Andrew suggest something similar for a sound driver.
thanks
-john
--- 1.68/drivers/net/tg3.c Wed Apr 23 20:02:11 2003
+++ edited/drivers/net/tg3.c Mon May 5 11:39:08 2003
@@ -2191,7 +2191,7 @@
spin_unlock_irqrestore(&tp->lock, flags);
- return IRQ_RETVAL(handled);
+ return IRQ_HANDLED;
}
static void tg3_init_rings(struct tg3 *);
On Tue, 2003-05-06 at 15:03, john stultz wrote:
> Not sure if this is the proper fix, but it stops the kernel from
> complaining. I saw Andrew suggest something similar for a sound driver.
Definitely not the right fix. If the hardware status struct
indicates no event is pending, then we return 0 since we
didn't "handle" the interrupt.
Otherwise, whats the point of the irqreturn_t at all? :-)
--
David S. Miller <[email protected]>
"David S. Miller" <[email protected]> wrote:
>
> On Tue, 2003-05-06 at 15:03, john stultz wrote:
> > Not sure if this is the proper fix, but it stops the kernel from
> > complaining. I saw Andrew suggest something similar for a sound driver.
>
> Definitely not the right fix. If the hardware status struct
> indicates no event is pending, then we return 0 since we
> didn't "handle" the interrupt.
This is about the fifth report of unhandled interrupts. Against the fifth
driver which looks to be correct.
So I'd be suspecting the scenario which Alan outlined: the IRQ handler looped
around, scooped up the interrupt source before the APIC delivered the IRQ.
I'm working on the actual detection code - it tries to filter out the false
positives.
Suggest we ignore these reports until that is sorted out.
From: Andrew Morton <[email protected]>
Date: Tue, 6 May 2003 22:08:02 -0700
So I'd be suspecting the scenario which Alan outlined: the IRQ
handler looped around, scooped up the interrupt source before the
APIC delivered the IRQ.
That certainly what happens with tg3.
Suggest we ignore these reports until that is sorted out.
Ok.
Andrew Morton wrote:
>>
>> Definitely not the right fix. If the hardware status struct
>> indicates no event is pending, then we return 0 since we
>> didn't "handle" the interrupt.
>
> This is about the fifth report of unhandled interrupts. Against the fifth
> driver which looks to be correct.
>
> So I'd be suspecting the scenario which Alan outlined: the IRQ handler looped
> around, scooped up the interrupt source before the APIC delivered the IRQ.
>
> I'm working on the actual detection code - it tries to filter out the false
> positives.
On thinking about it further, I don't think you will ever be able to write
such code -- whether "interrupt received but no pending work" is an error
or not is a private matter between the driver and its device. All you can
really ask the driver for is "was that interrupt generated by your device?"