Bug 350431

Summary:	eth0: too many iterations (6) in nv_nic_irq.
Product:	[Fedora] Fedora	Reporter:	Jim Deas <jim.deas>
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	7	CC:	aabdulla, chris.brown, davej, gilboad, netllama, wtogami
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-01-16 22:57:54 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jim Deas 2007-10-24 13:10:31 UTC

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

Comment 1 Jim Deas 2007-10-24 13:45:32 UTC

Hardware:
Tyan S2932 (nForce Pro 3600 chipset)
(1) Dual core Opteron
4G RAM

Comment 2 Chuck Ebbert 2007-10-24 20:54:31 UTC

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

Comment 3 Jim Deas 2007-11-02 16:26:20 UTC

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.

Comment 4 Chuck Ebbert 2007-11-02 16:50:41 UTC

(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"

Comment 5 Jim Deas 2007-11-02 19:41:36 UTC

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.

Comment 6 Christopher Brown 2008-01-16 02:58:03 UTC

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.

Comment 7 Jim Deas 2008-01-16 22:57:54 UTC

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.