2009-04-05 08:19:58

by Jesper Krogh

[permalink] [raw]
Subject: eth0: too many iterations (16) in nv_nic_irq.

I have a 2.6.29 kernel which fills up the "dmesg-buffer" with these:

eth0: too many iterations (16) in nv_nic_irq.

$ dmesg | grep -c "too many iterations"
1986

I have seen the commit below.. is the fix just to set the limit to 30
instead? or is there a "real bug" underneath?

commit dccd547e2bf2c01a13c967ae03a705338394fad6
Author: Joe Korty <[email protected]>
Date: Wed Oct 29 14:22:16 2008 -0700

forcdeth: increase max_interrupt_work

This eliminates the following often-generated warning from my 64 bit
Opteron SMP test stand:

eth0: too many iterations (6) in nv_nic_irq

According to the web, the problem is that the forcedeth driver has a
too-low value for max_interrupt_work. Grepping the kernel I see that
forcedeth has the second lowest value of all ethernet drivers (ie, 6).
Most are in the 20-40 range. So this patch increases this a bit,
from 6
to 15 (at 15 forcedeth becomes the driver with third-lowest
max_interrupt_work value).

My test stand, which used to print out the above warnings repetitively
whenever it was under heavy net load, no longer does so.

Signed-off-by: Joe Korty <[email protected]>
Cc: Ayaz Abdulla <[email protected]>
Cc: Jeff Garzik <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Jeff Garzik <[email protected]>


2009-04-06 14:25:43

by Joe Korty

[permalink] [raw]
Subject: Re: eth0: too many iterations (16) in nv_nic_irq.

On Sun, Apr 05, 2009 at 04:19:35AM -0400, Jesper Krogh wrote:
> I have a 2.6.29 kernel which fills up the "dmesg-buffer" with these:
>
> eth0: too many iterations (16) in nv_nic_irq.
>
> $ dmesg | grep -c "too many iterations"
> 1986
>
> I have seen the commit below.. is the fix just to set the limit to 30
> instead? or is there a "real bug" underneath?

Probably. Still it is worth trying the '30' as an experiment.

The underlying cause is likely to be something on your system
holding off the eth0 interrupt for short periods of time.
An SMI is one such possibility.

I can't help but wonder if the printk itself is causing enough
of a delay to make this condition reoccur indefinately, under
sufficiently heavy net load, once it occurs once. It might be
better to instead use printk_ratelimit.

Joe


> commit dccd547e2bf2c01a13c967ae03a705338394fad6
> Author: Joe Korty <[email protected]>
> Date: Wed Oct 29 14:22:16 2008 -0700
>
> forcdeth: increase max_interrupt_work
>
> This eliminates the following often-generated warning from my 64 bit
> Opteron SMP test stand:
>
> eth0: too many iterations (6) in nv_nic_irq
>
> According to the web, the problem is that the forcedeth driver has a
> too-low value for max_interrupt_work. Grepping the kernel I see that
> forcedeth has the second lowest value of all ethernet drivers (ie, 6).
> Most are in the 20-40 range. So this patch increases this a bit,
> from 6 to 15 (at 15 forcedeth becomes the driver with third-lowest
> max_interrupt_work value).
>
> My test stand, which used to print out the above warnings repetitively
> whenever it was under heavy net load, no longer does so.
>
> Signed-off-by: Joe Korty <[email protected]>
> Cc: Ayaz Abdulla <[email protected]>
> Cc: Jeff Garzik <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> Signed-off-by: Jeff Garzik <[email protected]>