+++ 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) Gecko/20051111 Firefox/1.5 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.
Hardware: Tyan S2932 (nForce Pro 3600 chipset) (1) Dual core Opteron 4G RAM
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. > That's "pci=nomsi"
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.
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the Fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage 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.