Red Hat Bugzilla – Bug 350431
eth0: too many iterations (6) in nv_nic_irq.
Last modified: 2008-01-16 17:57:54 EST
+++ This bug was initially created as a clone of Bug #179422 +++
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8)
Description of problem:
The kernel likes to print "eth0: too many iterations (6) in nv_nic_irq." all the
time. This did not happen with FC4 on the same hardware.
I am finding that using forcedeth as part of a lacp bonding pair is freezing up
my system. I have replaced the nv GB dual channels built into the motherboard
with a dual broadcom card. The system is now stable. Given that the system
freezes up with no log information about the crash keeps me from posting more
information other than the 100's of nv_nic_irq messages. I can relate that it
appears to happen as new clients access the system using ssh or atalk. In
testing or with a single user I was not able to reproduce the problem.
I do have hardware on site for testing if I can get guidance on what testing
should be run on the nv driver.
Tyan S2932 (nForce Pro 3600 chipset)
(1) Dual core Opteron
What does /proc/interrupts contain? Is the driver using MSI interrupts?
They can be disabled, check the output of 'modinfo forcedeth' for the parameters
that can be set. Edit /etc/modprobe.conf and add, e.g.
options forcedeth msi=0 max_interrupt_work=8
The driver is using MSI but it can not be disabled using your suggestion.
I tried both a boot setting (pci_nomsi) and the modprobe setting above.
In both cases on reboot the Nv chipset was still shown as using MSI.
Is it possible the the motherboard can only support MSI? The ethernet chips are
built onto the motherboard itself.
Tyan S2932 4G RAM, 1 Dual core Opteron processor.
(In reply to comment #3)
> The driver is using MSI but it can not be disabled using your suggestion.
> I tried both a boot setting (pci_nomsi) and the modprobe setting above.
> In both cases on reboot the Nv chipset was still shown as using MSI.
Oops. Two weeks of beating my head against a wall must be taking its toll.
Typing the commands correctly helps.....
I am reseting two identical hardware systems via lacp though a Extreme series
switch. Once completed I can retest the setup with a multi-user load.
As it takes a serious load of several processes it may take some time for me to
make a reproducable test.
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
This bug did no resurface with the new hardware. Turns out I had a run of
motherboards with an interrupt issue. Using nomis masked the issue but the only
fix is exchanging the hardware.