Ethernet (nVidia MCP55) not working [ gutsy, hardy, interpid ]

[Black Sliver]

I've tried the Ubuntu Gusty Gibbon Tribe 5 live disc (x86) and the netboot variant (x86 too, netboot worked fine). Both can't access my network! Everything works fine using Feisty x86 (as-is) and Windows XP Home (with installed drivers).
My two network cards are on-board, only eth0 plugged, both are nVidia nForce MCP55.

Because default settings were'nt working, I switched to static and executed ifconfig, after that I've tried dhcp again and ran /etc/init.d/networking restart, after that, again ifconfig. See: http://pastebin.ca/679166
Here's my dmesg output: http://pastebin.ca/679163

On FEISTY, my hardware infos:
lspci -v: http://pastebin.ca/679184
lshw: http://pastebin.ca/679180

For any questions, please mail to andreas.lausch[at]tbt.at or /msg BSliver on #ubuntu @ EFNet

[Tom Worley (tom-worley)]

I've had exactly the same problem, however just found the solution:
In the Gusty Tribe 5 live installer, open a terminal:

$ sudo su
# rmmod forcedeth
# modprobe forcedeth msi=0 msix=0
# /etc/init.d/networking restart

Your network interfaces should come back up and actually work now :-)

[Joe Smith (yasumoto7)]

Sweet, thanks Tom :)

[Black Sliver (andreas-lausch)]

Thanks Tom!

Let's see if it works - more in 18 hours. :)

[Nanley Chery (nanoman)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in it recently. We were wondering is this still an issue for you? Can you try with latest Ubuntu release? Thanks in advance.

[Black Sliver (andreas-lausch)]

Oh.. sry, I forgot to answer.
It's working without any problems (power on -> gbit connection) on the final release of gutsy :)
The work 'round for for tribe 5 worked also, if i remember correctly.

[daInvincibleGama (dainvinciblegama)]

I'm getting this bug on Ubuntu Hardy Alpha5.

The workaround helps, but I need to do it everytime I reboot, and it gets annoying.

[Black Sliver (andreas-lausch)]

You can try to add this script to your RC or at least write a sh script.

[Black Sliver (andreas-lausch)]

Well.. i have now 3 minutes to explain it :D

Run gedit or kwrite as root and open /etc/rc.local
Atl+F2 -> gksu gedit /etc/rc.local on ubuntu
Run -> kdesu kwrite /etc/rc.local on kubuntu

Paste the lines from above between the comment lines and exit0.

May I ask you for your card's vendor and name? Is it exactly the same i am using?

[daInvincibleGama (dainvinciblegama)]

Thnx for the startup edit thing.

My card is inboard ethernet on ASUS P5N32-E SLI plus. Its a 650i northbridge board, with a 590/570a southbridge. The LAN chips are off of the northbridge I think.

Now that I think about it, I used to have a weird bug when I was running Vista that would show up rarely. I just had to disable/enable it and it would work. Nothing like that on XP though.

[saads (shakhshir)]

This bug exists on Ubuntu Hardy Beta. When booting the system there is no network using the nVidia MCP55 Ethernet controller. Running the commands given by Tom Warley in the first comment above fixes the issue.

[jad (jad-jadickinson)]

This worked for me

Add the following line to /etc/modprobe.d/options

options forcedeth msi=0 msix=0

Then rebuild initramfs like this

sudo update-initramfs -u

and remove any stuff you added to /etc/rc.local

Reboot.

NOTE: if the update-initramfs bit goes wrong it could stop your system from booting - don't blame me - make sure you know how to fix it first.

[Nanley Chery (nanoman)]

Setting to linux - this is a kernel problem isn't it?

[Jakub Argasiński (argasek)]

Confirming on Hardy beta; indeed, it's a kernel (actually, forcedeth driver) bug. Forcedeth driver is known to fail for some reason if Message Signalled Interrupts (MSI) are enabled.

lspci -v:
00:11.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
        Subsystem: ASUSTeK Computer Inc. Unknown device 81fb
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 506
        Memory at efffa000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at ec00 [size=8]
        Memory at efff9000 (32-bit, non-prefetchable) [size=256]
        Memory at efff8000 (32-bit, non-prefetchable) [size=16]
        Capabilities: [44] Power Management version 2
        Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
        Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable+
        Capabilities: [6c] HyperTransport: MSI Mapping

00:12.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
        Subsystem: ASUSTeK Computer Inc. Unknown device 81fb
        Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 507
        Memory at efff7000 (32-bit, non-prefetchable) [size=4K]
        I/O ports at eb00 [size=8]
        Memory at efff6000 (32-bit, non-prefetchable) [size=256]
        Memory at efff5000 (32-bit, non-prefetchable) [size=16]
        Capabilities: [44] Power Management version 2
        Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
        Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable+
        Capabilities: [6c] HyperTransport: MSI Mapping

Asus P5NT WS motherboard.

[zephirum (zephirum)]

interesting, this might be why I can't, for the life of me, seem to get the network going.
I'm using Asus P5N32- SLI motherboard.

It is strange, because the network problem seems to fail only with recent version of Ubuntu,
I found an old CD and it seems to work ok...

I will update more once I try this out.

[zephirum (zephirum)]

Yeap, the command by Tom works miracle.
I hope they can fix this bug soon, because a network problem simply stops people from trying out Ubuntu (and the problem seems to apply in Kubutu as well) because they can't access support online easily if the network is down. Not everyone has the patience to log in and out of Windows to try out each single tip.

[Darek (travelling-student)]

This was a problem for me in Ubuntu 8.04. Spent a good four hours looking at the problem and trying various fixes; the post by Tom was extremely helpful, but in no way would I have figured it out on my own. I agree with the above poster; regular users will not spend this amount of time trying to fix something they take for granted.

[burgwinkel (burgwinkel)]

This became a problem for me on one system (of three) I upgraded to Hardy. The 'options forcedeth msi=0 msix=0' fix seems to be working on Hardy. Never had an issue that I am aware of on Gutsy involving forcedeth.

I seem to be able to reproduce a loss of network (using synaptic, for example) without the fix in place. Is there some debugger I can run on this, or is this bug adequately documented already?

Here's lspci -v

00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
 Subsystem: ASUSTeK Computer Inc. Unknown device 8239
 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10
 Memory at fe02a000 (32-bit, non-prefetchable) [size=4K]
 I/O ports at b000 [size=8]
 Memory at fe029000 (32-bit, non-prefetchable) [size=256]
 Memory at fe028000 (32-bit, non-prefetchable) [size=16]
 Capabilities: [44] Power Management version 2
 Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
 Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable-
 Capabilities: [6c] HyperTransport: MSI Mapping

On an Asus M2N SLi mobo

[Yann Sionneau (yann-sionneau)]

I had the same problem with embedded nForce NVIDIA network controller.
The fix consisting in putting "options forcedeth msi=0 msix=0" in in the interface file (and then "sudo update-initramfs -u") worked for me as well.
thank you :)

[Tim Gardner (timg-tpi)]

This bug does not qualify for an SRU fix. The workaround is well known, though I agree that it may not be obvious to most users.

[Sarah Kowalik (hobbsee-deactivatedaccount)]

and intrepid?

[Black Sliver (andreas-lausch)]

The Hardy alternate setup told me it can not configure my Ethernet (via DHCP) but I had a working DHCP network connection after logging into the fresh installation. Hardware is the same as in the first post.

[Yann Sionneau (yann-sionneau)]

Hello,
i find this bug a very critical one, since new {linux,ubuntu} users won't search deeper if their network interface don't work.
They won't search in the launchpad or in google for a fix.
They may continue using ubuntu even if some application doesn't work in the way they want it to, thinking that it can be configured later, but for this kind of bug there is a high probability that they just think that their hardware is just not supported and just give up with linux or ubuntu.
I always thought that ubuntu was a distribution that made the most possible to prevent new users from giving up because of loss of courage.
So here is my question : why no fixing this bug since the only thing to do is adding a single line to a text file ?
i searched for "SRU" and i found out it is "Stable Release Updates" , so i searched for the requiered property for a bug to have his SRU fix.
And i honestly think that this bug fits the requiered conditions, i quote :
"Bugs which represent severe regressions from the previous release of Ubuntu. This includes packages which are totally unusuable, like being uninstallable or crashing on startup."
indeed, the driver used to work well without any changes of options in gutsy and feisty so there is abviously a regression.
"Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel)."
Since the patch only consist in adding a single line to a text file i think we can conclude that the patch is obviously safe.

So, can somebody explain me why this bug won't be fixed ?

[Tim Gardner (timg-tpi)]

Fallen-Angel: The most important tenant of the SRU process is 'cause no regressions in the current release'. The fact that this issue is a regression from Gutsy to Hardy only makes it elegible for SRU scrutiny. In this case, I cannot guarentee that disabling MSI for all cases won't cause regressions. Disabling MSI will most certainly cause performance regressions on already working platforms. I agree that some folks won't use Ubuntu because of this, but I can't always satisfy everyone.

Sarah Hobbs: Without blowing smoke, I couldn't tell you if Intrepid will fix this issue. Users can try the development Intrepid kernel from the kernel-ppa at http://ppa.launchpad.net/kernel-ppa/ubuntu.

[Jakub Argasiński (argasek)]

There's no need to disable MSI for the whole kernel, one can fix this applying appropriate flags to a forcedeth module (see comment #11).

[Yfrwlf (yfrwlf)]

The above fixes worked great, have an Asus P5N32-E SLI Plus motherboard. It's too bad this problem cannot be fixed for only the machines that are having the problem through a system update without breaking things for working machines. If only it was a bug that was clearly at fault so that the fix could be pushed out, but oh well, guess that's a fix for Ubuntu 8.10.

[Sami Näätänen (sn-ml)]

I haven't yet tested this on Ubuntu, but with 2.6.25-gentoo-r3 kernel on Gentoo I got hangups with eventual tx ring flushing if I used msi=0 msix=0.
So I tested with msi=1 msix=0 and everything have worked after that. I will add my experiences after I can install my ubuntu/kubuntu.

I had this problem if I had heavy write load to my nfs server from the this problematic machine, when I used the msi=0 msix=0 options.
Now with msi=1 msix=0 that's fixed.

If others could test this too, this could help narrow the code path that's causing this.

[Henri Cook (henricook)]

I had this problem in Hardy, if it's somehow been marked as something that doesn't need to be fixed the person doing the classifying is a fool.

Gutsy -> Hardy users see this as a regression (at least I did, my on board nvidia MCP55 worked fine in Gutsy) - a reformat and lots of fiddling around later and I finally find this page so that I can start using Ubuntu as I used to.

- Inconveniences existing users, possibly discouraging them back to Windows/Mac
- Inconveniences new users - completely putting them off Ubuntu and possibly linux

The fix is not obvious. Forcedeth need to get their act into gear, someone needs to poke them. This is a serious, serious problem - look at the amount of mobos with nvidia chipsets!

[Stefan Bader (smb)]

Does someone care to try the Hardy kernel at http://people.ubuntu.com/~smb/bug136836? This is a first try so maybe this does not work out. In any case if you test it, please submit your lspci -vvnn info for the ethernet and the debug lines that get printed for msi_enabled/msix_enabled.

[Yann Sionneau (yann-sionneau)]

In response to Stefan Bader's post :
I tried your linux-image-2.6.24-19-generic_2.6.24-19.35smb2_i386.deb
When i boot up it worked but i have to say that i added "options forcedeth msi=0 msix=0" to my /etc/modprobe.d/options
Do you want me to test without this line ?
Here is my dmesg | grep forcedeth :
[ 54.326399] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
[ 54.326705] forcedeth 0000:00:11.0: msi_enabled=0 msix_enabled=0
[ 54.844639] forcedeth 0000:00:11.0: ifname eth0, PHY OUI 0x5043 @ 19, addr 00:1a:92:2b:76:4d
[ 54.844642] forcedeth 0000:00:11.0: highdma csum vlan pwrctl mgmt timirq gbit lnktim desc-v3
[ 54.844959] forcedeth 0000:00:12.0: msi_enabled=0 msix_enabled=0

Here is my lspci -vvnn :
00:11.0 Bridge [0680]: nVidia Corporation MCP55 Ethernet [10de:0373] (rev a2)
 Subsystem: ASUSTeK Computer Inc. Unknown device [1043:cb84]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0 (250ns min, 5000ns max)
 Interrupt: pin A routed to IRQ 18
 Region 0: Memory at efffa000 (32-bit, non-prefetchable) [size=4K]
 Region 1: I/O ports at ec00 [size=8]
 Region 2: Memory at efff9000 (32-bit, non-prefetchable) [size=256]
 Region 3: Memory at efff8000 (32-bit, non-prefetchable) [size=16]
 Capabilities: [44] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
  Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
 Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
  Vector table: BAR=2 offset=00000000
  PBA: BAR=3 offset=00000000
 Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable-
  Address: 0000000000000000 Data: 0000
  Masking: 00000000 Pending: 00000000
 Capabilities: [6c] HyperTransport: MSI Mapping

00:12.0 Bridge [0680]: nVidia Corporation MCP55 Ethernet [10de:0373] (rev a2)
 Subsystem: ASUSTeK Computer Inc. Unknown device [1043:cb84]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
 Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
 Latency: 0 (250ns min, 5000ns max)
 Interrupt: pin A routed to IRQ 19
 Region 0: Memory at efff7000 (32-bit, non-prefetchable) [size=4K]
 Region 1: I/O ports at eb00 [size=8]
 Region 2: Memory at efff6000 (32-bit, non-prefetchable) [size=256]
 Region 3: Memory at efff5000 (32-bit, non-prefetchable) [size=16]
 Capabilities: [44] Power Management version 2
  Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
  Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
 Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
  Vector table: BAR=2 offset=00000000
  PBA: BAR=3 offset=00000000
 Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable-
  Address: 0000000000000000 Data: 0000
  Masking: 00000000 Pending: 00000000
 Capabilities: [6c] HyperTransport: MSI Mapping

Hope it helped.
If you want more tests, just tell me, i would be glad to help you solve this problem.

[Yann Sionneau (yann-sionneau)]

I tried commenting the line "options forcedeth msi=0 msix=0" in my /etc/modprobe.d/option
After a reboot it works too and i have exactly the same output doing a
dmesg | grep forcedeth (or cat /var/log/syslog | grep forcedeth) and lspci -vvnn

[Stefan Bader (smb)]

That was the hope. ;-) There are several places where msi and msix come into place. One is the definitions per hardware in forcedeth but I noticed in the lscpi output os some of you that posted that there is a msi and msix enabled flag for the pci bus. The question is whether for those that would have a board with one of those enabled, whether it gets enabled for the forcedeth as well. In other words does my debug line match that info that you get from lspci -vvnn? And are there some that get 1 for one if them with the driver making use of that.

[Stefan Bader (smb)]

On a second thought I think this was wrong thinking. Seems there is code to try to enable msi or msix later. It would be great if someone could supply a dmesg log for the non-working case.

[Yann Sionneau (yann-sionneau)]

Hi again !
Just a little message to say that i upgraded to latest linux-image-2.6.24-19-generic_2.6.24-19.36_i386.deb (so it overwrote yours) and after a reboot the problem was here again.

Just to point the fact that the problem still exists in the latest ubuntu kernel update.

Hope you will manage to fixe this, i remind you that i'm stil available to test your .deb if you want.

Keep us informed of your improvements :)

Thank you !

[Stefan Bader (smb)]

It is sure there. I did not really fix it. I rather disabled a setting by default. And that was not a good fix. Actually it would be great if you or anybody else could provide me with some data (dmesg working/non-working and the lvpci -vvnn output).

[Zooko Wilcox-O'Hearn (zooko)]

I have this consistently. It takes a few hours to trigger, typically, but when it does it locks up my linksys router (presumably the Linux workstation is sending packets at such a rate that it overloads the linksys, I dunno, but if I unplug the ethernet cable then the linksys router comes back to life) at the same moment as locking up the workstation itself. Disabling the Marvell 88E1116 in the BIOS makes the problem go away, but then I don't have ethernet.

Right now I'm downloading Linux kernel 2.6.26 to see if that fixes it. (I've already tried 2.6.25 and it had the same problem.)

I'll keep you posted.

[AGMaster (aryeh2007)]

Sorry about this but im really confused! I get the temporary fix and do the following every time I log on

sudo su
rmmod forcedeth
modprobe forcedeth msi=0 msix=0
/etc/init.d/networking restart

However I need a permanent fix. I tried to make this run every time I log in (This is is stored in a plain text file in my documents folder) but after sudo su I need to type in my password, So it doesn't work!

Can anyone please explain, in relatively "human" English, what I should do to fix this permanently!

Thanks in advance,

AGMaster

[Stefan Bader (smb)]

To get this settings permanent create (as root) /etc/fmodprobe.d/orcedeth (or update /etc/modprobe.d/config). Add the line:

options forcedeth msi=0 msix=0

and save. Then rebuild the initramfs with

update-initramfs -u -k $(uname -r)

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[kieron (kieron-kieroni)]

I appreciate your workaround Stefan, and it worked for me for a few days, however today it doesn't, /etc/fmodprobe.d/orcedeth is still there with the options line and I tried rebuilding the initramfs again but no go.

The only thing that's changed in the interim is I installed turboprint (surprise surprise as my canon mp800 printer isn't supported) I don't know how that could have changed things but I can't think of anything else.

I wanted to get ubuntu working and switch to it but the fact that you need to be a computer geek to use it (and I'm obviously not geek enough with 10 years of programming experience and I don't have any more weeks of my life I'm prepared to waste on it) and the fact that this bug is not considered important enough to be dealt with in an update, means it's back to windows for me.

This network card was (and still is as far as I know) the standard one for mesh computers in the uk and they supply a large number of pc's. Still there we go.

Sorry if I sound like a moany old git, I'm just disappointed.

[Stefan Bader (smb)]

I can understand your disappointment but please take into account that in Linux it is the geeks and the users that have to work around broken or strange hardware while for other OS the vendors care more.
For your problem: you could check whether the network card is running in the wrong mode by looking at the output of 'cat /proc/interrupts'. in MSI/-X mode the interrupt number is usually one above 200, while otherwise you get one below that.
If the card is running in MSI/-X mode and you want a quick solution without minding a slight performance hit, you might try "nomsi" as an option added to the grub options.
But if your card is not in MSI mode, this would be a different issue and probably needs more investigation. And I am afraid this will require some time and effort.

[Zooko Wilcox-O'Hearn (zooko)]

kieron: I'm sorry to hear you are going back to Windows. Good luck!

Everyone: I upgraded my kernel to the upstream Linus-Torvalds-official 2.6.27 release candidate, and the problem went away. I was getting the problem reliably until then, so I'm pretty sure one of the several forcedeth patches in that kernel fixed it. Since Intrepid is going to us 2.6.27, I expect this problem to be fixed in Intrepid. By the way, I've been upgrading to newer 2.6.27 release candidates (or actually git snapshots) every now and then and the problem hasn't recurred.

[kieron (kieron-kieroni)]

Thanks for such a swift response Stefan, naturally I appreciate what you say about working around broken and/or strange hardware and I'm grateful people such as yourself work on and contribute to fixing things for people like me - my concern was that Linux will always stay in the shadows of windows until such time that the everyday user can operate it with no hardware concerns and no need to use the terminal (n.b. I'm not speaking for myself, I have no problem with the terminal!)

As it is I forgot to mention I'm dual booting ubuntu and having booted into windows and back into ubuntu I now have an internet connection! Either that has significance of some kind or my problem is inconsistent and intermittent.

The 'interrupt number' you're referring to is that 'eth0' interrupts? I believe the card is running in MSI/-X mode, but I'll save the 'nomsi' option for repeated problems.

Zooko: Yes I certainly need luck, I've spent more time sitting through urgent update reboots with vista in the past month than I have working. How stable is 2.6.27? I may well recompile the kernel if I have the time/inclination!

[Stefan Bader (smb)]

>As it is I forgot to mention I'm dual booting ubuntu and having booted into windows and back into ubuntu
> I now have an internet connection! Either that has significance of some kind or my problem is
>inconsistent and intermittent.

Right this can unfortunately happen both ways. One driver leaves or sets a device into a state the other cannot or accidentally does not handle well.

Yes, this is what it might look with MSI:
220: 0 0 PCI-MSI-edge eth0
And this without:
 21: 0 0 IO-APIC-fasteoi eth0
(note I quickly grabbed those from 2 different system, which probably run different kernels, so it must not be exactly like that. ;-))

[jad (jad-jadickinson)]

kieron

I expect this is stating the obvious but just in case - There is a typo in Stefan Bader's message it should read

/etc/modprobe.d/forcedeth

not

/etc/fmodprobe.d/orcedeth

FWIW - I made this change back on April 15th (See earlier post) on my system and it has run fine ever since. IIRC kernel updates rebuild initramfs and pick up the forcedeth options so once you have it working you never need to do anything again.

HTH

[Matt Zimmerman (mdz)]

It has been stated that this is expected to be fixed in 2.6.27, which would mean that it's fixed with Intrepid.

Could someone affected by the bug either upgrade to Intrepid or boot from the live CD to test?

The ISOs are available at http://releases.ubuntu.com/8.10/

[Zooko Wilcox-O'Hearn (zooko)]

On Oct 16, 2008, at 10:05 AM, Matt Zimmerman wrote:

> It has been stated that this is expected to be fixed in 2.6.27, which
> would mean that it's fixed with Intrepid.
>
> Could someone affected by the bug either upgrade to Intrepid or boot
> from the live CD to test?

The problem has gone away for me once I upgraded to a 2.6.27
prerelease (official Linus kernel). Now I'm on 2.6.27-final
(official Linus kernel) and the problem remains gone.

Regards,

--Zooko
---
http://allmydata.org -- Tahoe, the Least-Authority Filesystem
http://allmydata.com -- back up all your files for $5/month

[Stefan Bader (smb)]

Based on the last comment (and the previous ones that indicated this has been improved in 2.6.27) I close this bug as fixed for Intrepid. For Hardy and Gutsy this has to be worked around by disabling MSI(X).

[nkcss (ubuntu-nickkusters)]

I just installed Ubuntu 8.10, and I'm afraid I have the same problem, so this bug is not solved.

[Mark Rijckenberg (markrijckenberg)]

Hi,

Jonathan Perryman also has this issue on Ubuntu 8.10.

Take a look at https://answers.launchpad.net/ubuntu/+question/49556 for details.

Regards,

Mark Rijckenberg

[Zooko Wilcox-O'Hearn (zooko)]

Just a recap of my experience to help anyone who is trying to figure out whether the problem is fixed or not.

I had a problem which had similar or identical symptoms to the problems other people reported. The problem happened reliably.

I did not try the workaround of passing "msi=0 msix=0".

I did instead upgrade my kernel from the Hardy kernel to Linus's 2.6.25, then to Linus's 2.6.26, then to a pre-release of Linus's 2.6.27. Once I switched to the pre-release of Linus's 2.6.27 the problem went away. Remember, the problem happened reliably, so there is no question that the only thing that I changed was changing my kernel to the 2.6.27-prerelease-from-Linus and there is no question that this change fixed the problem for me.

Then I kept upgrading my kernel to newer git snapshots of Linus's kernel throughout the 2.6.27-prerelease process, and the problem did not recur. The I upgraded my kernel to 2.6.27-final from Linus and the problem did not recur. Then I upgraded my kernel to the 2.6.27.x stable releases from the GregKH Stable Team and the problem did not recur.

So, it could be that the problem I had was different than the problems other people had, which is why other people upgrading to Intrepid with the Ubuntu-2.6.27 kernel didn't fix theirs even though me upgrading to Linus-2.6.27 fixed mine. Or it could be that the problem I had is the same as what other people have, but there is some difference between Ubuntu-2.6.27 and Linus-2.6.27 so that the former doesn't fix the problem but the latter does. Oh, and there is another consideration which is that my kernel config is a custom kernel config of my own choosing, so it could be that applying my kernel config instead of the Ubuntu kernel config to either the Ubuntu-2.6.27 or the Linus-2.6.27 would change whether this bug occurs.

I am very busy with other projects right now, so I am not planning to experiment any more with my system (which now works). Good luck!

[Zooko Wilcox-O'Hearn (zooko)]

P.S. In case this isn't clear, a pretty good Next Step for someone who wants to debug this problem might be to try the Linux-GregKH-official-Linus-2.6.27.x kernel instead of the Ubuntu-2.6.27 kernel. I haven't checked, but I presume that the Ubuntu kernel is not precisely the same as the official kernel source code.

Okay, tell you what: If someone tries that, and it doesn't fix the problem, then I will agree to (a) share my kernel config with someone so they can see if my kernel config instead of the Ubuntu kernel config changes the behavior, and/or (b) try the Ubuntu kernel config and or kernel source tree myself. This (b) option is kind of inconvenient because I am not going to upgrade my workstation from Hardy to Ibex...

[weixelgeist (gw-weixdach)]

Hi,
i have the same problem with the same motherboard (Asus P5N32-SLI Premium).
But the workaround does not work for me!

[zephirum (zephirum)]

 Stefan Bader wrote on 2008-10-16: (permalink)

>Based on the last comment (and the previous ones that indicated this has been improved in 2.6.27) I close this bug as fixed for Intrepid. >For Hardy and Gutsy this has to be worked around by disabling MSI(X).

Nope, the problem is still there and the constant attempt to connect to the network almost disabled my router.
Considering nVidia chipsets being (ever) so prevalent, I'm suprised this is not taken more seriously.

[Stefan Bader (smb)]

This is not taken lightly but the original problem (MSI(X)) seemed to be solved in more recent kernels and there was a work-around for the older ones. By saying the problem is still there, it is not clear to me whether it is the MSI problem. Can you use the driver with "msi=0 msix=0"?

[zephirum (zephirum)]

Hi, thanks for the speedy reply. I'm currently using a fresh install of 8.10, but it would still seek for network connection in vain.The "msi=0 msix=0 "fix still works. However, it appears that I'm suffering a memory leak problem now, which may be related to the networkmanager. Please refer to bug #291074.

Essentially the symptoms are:
Warning messages at syslog (attached at the page)

<WARN> nm_error_monitoring_device_link_state():error monitoring wired ethernet link state: error occured while waiting for data on socket.
last message repeated (a very very big number here) times

while at the same time, memory usage creeps up, then swap file, then system hangs forcing a restart.

In fact, in retrospect, I think this memory leak problem exists even before the msi=0 fix. With my very limited knowledge in Linux, is there a way for me to try and disable networkmonitor to test this theory?

[Stefan Bader (smb)]

For the MSI problem probably the best way to proceed would be to try out the latest vanilla kernel and if that fails as well go and open an upstream bug. Unfortunately MSI can break on various levels (IO-APIC - pci bridge - card), so it can work for some and still fail for others.

The second problem: I hope I remember this correctly but I think if you put a matching configuration of your card into /etc/network/interfaces, it won't be managed by NM.
Which would make me think the following should prevent NM from doing anything:

auto eth0
iface eth0 inet dhcp

[zephirum (zephirum)]

I'm not sure how to install a new kernel on Ubuntu, so I'm afraid I cannot provide you with more information in that regard. I will try and read up a bit on how that's done this weekend, but I suspect it won't be easy for a novice like me.

Unfortunately the command you gave only disabled the nm applet, but network manager still ticks away eating up all 3GB of RAM. I eneded up (somehow) killing the networkmanager process and perserved my internet connection.

[Andreas Petlund (andreas-petlund)]

I've tested the current development kernel (2.6.28-rc3) on my computer (Asus P5N32-SLI Premium motherboard), and the problem is still present. I can take this to the mailing lists to try to find a reasonable solution.

[Andreas Petlund (andreas-petlund)]

I got no suggestions/feedback when posting this question on the netdev-list, but I have done some experimenting with msi disabling for affected devices in order to produce a (preliminary) patch. What I would like to know is if there are other motherboards than the Asus P5N32-SLI Premium which are affected by this. I also would like to know if any of you have the Asus P5N32-SLI motherboard with other, working msi-enabled devices (to find out if this may be a global msi problem or limited to the MCP55-NIC).

You can find out if a device has active msi by doing 'cat /proc/interrupts'. An "IO_APIC" is a pin-signalled device, while
"PCI-MSI" represents msi-enabled devices.

[Zooko Wilcox-O'Hearn (zooko)]

I have "286: 206342002 PCI-MSI-edge eth0".

My motherboard is gigabyte GA-M57SLI-S4 (because it allegedly can run openbios, not that I've tried that).

Remember, all my problems were fixed by upgrading to the upstream-linux-gregkh 2.6.27.

[Andreas Petlund (andreas-petlund)]

Thanks for the feedback. I'm primarily trying to find out if this is P5N32-SLI-specific, so a clarification of the above question is: Are there anybody (in addition to me) who still experiences the network problems after upgrading to 2.6.27+ and has other motherboards than the Asus P5N32-SLI Premium?

[Mazhar Subzwari (msubzwari)]

I was having problems with large data transfers. My PC's intergrated ethernet port used to go down & come up in a few seconds by itself. The solution given above resolved my problem. Though my hardware is differnet, this seems to be a general issue with forcedeth drivers on Ubuntu standard kernels.

I am using Hardy 64bit Server on Asus P5N-MX board.

Linux 2.6.27-7-server #1 SMP Tue Nov 4 20:16:57 UTC 2008 x86_64 GNU/Linux

lshw output:
 *-network
       description: Ethernet interface
       product: MCP73 Ethernet
       vendor: nVidia Corporation
       physical id: f
       bus info: pci@0000:00:0f.0
       logical name: eth0
       version: a2
       serial: 00:22:15:54:bb:9a
       size: 100MB/s
       capacity: 100MB/s
       width: 32 bits
       clock: 66MHz
       capabilities: pm msi bus_master cap_list ethernet physical mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
       configuration: autonegotiation=on broadcast=yes driver=forcedeth driverversion=0.61 duplex=full ip=192.168.100.101 latency=0 link=yes maxlatency=20 mingnt=1 module=forcedeth multicast=yes port=MII speed=100MB/s

[Andreas Petlund (andreas-petlund)]

After looking into the problem, I'm convinced that my problem (with the P5N32-SLI Premium mobo), is caused by a buggy BIOS. I also have the same PCI bridge and NIC on another Asus motherboard, where it works flawlessly (for small and large data transfers). I have submitted a kernel patch where msi is turned off as default for the P5N32-SLI Premium. The difference in behaviour suggests that the issue of theP5N-MX mobo is different from the P5N32-SLI Premium issue. Sadly, I cannot try to test and debug it since I don't have it. My advice is to submit this issue as a new bug.

[susyp (susyp)]

Thanks for your solution. It works by me too.
To Andreas Petlund: I have had the same network problem with an ASUS M2N-SLI Deluxe motherboard.
Strange is that this problem came forward after upgrade ubuntu 8.10 and I wasn't met it with 8.04.
I submit any aditional info what you need.

[xcut (xcut)]

I confirm this problem with Ubuntu 8.10, 64 bit, on an EVGA motherboard with an nforce 680i SLI chipset. The workaround using the forcedeth parameters and update-initramfs works.

How about you chaps ship that as the default kernel parameter for that module?

[Sami Mäkinen (sami-makinen-helsinki)]

For people reading this bug report: I have a similar issue that only happens after suspend: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/312144

For me networking works just fine, except for suspending, so I don't think any defaults should be modified, unless those defaults would fix the suspend problem. Testing shows that they do not fix it. So instead of hacking defaults for everybody, the remaining issues really should be fixed in the forcedeth driver, which should somehow detect which hardware works with current defaults and which hardware requires special settings.

[Andreas Petlund (andreas-petlund)]

I agree that a mechanism for detecting functionality with different values would be superior to the quirk workaround. I added that on the assumption that this was a one-time problem which was caused by a BIOS bug on the Asus P5N32-SLI Premium. Since different potentially related occurrences have surfaced since that, I definitely think that this should be looked into.

[Siva shankari (abi3719)]

Hello friends,

Im new to this launchpad. I have similar problem, with Asus Motherboard, and have been trying to fix it for so long. As few people has mentioned in the forum, its really annoying to fix this problem. Ive tried alot, and very very tired of it. Its really terrible, to switch between Ubuntu and Windows. And, eagerly, patiently, checking the forums with a hope that, atleast one day or other the problem, might get fixed. But thats not happening only. The following link, shows in detail, what are all the various options, ive tried.. Plz, plz if anyone can help me, in fixing this problem, it would definitely be a great help.

http://ubuntuforums.org/showthread.php?t=1032136

The problem is, ive to do my project in the Linux environment, where i need Internet connection, as must. Plz do help me ASAP.

Thanks in advance...

[attikon (attikon)]

##########################################
 Networking Solution for nVIDIA MCP55 Ethernet - Ubuntu 8.10 Interpid
##########################################

Step 1, open a terminal.

a) become superuser
$ sudo su

b) remove forcedeth kernel module (it's the ethernet's driver)
# rmmod forcedeth

c) load forcedeth kernel module again with new parameters
# modprobe forcedeth msi=0 msix=0

d) restart networking
# /etc/init.d/networking restart

You should be able to connect to your network now.

Step 2, configure the system to do this automatically from now on when it starts
(otherwise you'll need to do the above steps every time you boot).

Open a terminal and become root with
$ sudo su

a) go to /etc/modprobe.d/
# cd /etc/modprobe.d/

b) edit the options file
# gedit options

c) go to end of file and add the following lines (without the quotes)
"#nVIDIA Corporation MCP55 Ethernet"
"options forcedeth msi=0 msix=0"

d) save the changes and close gedit

e) you'll need to rebuild your boot image, in the same terminal type:
# update-initramfs -u

Reboot and you're done.

Hope this helps.

[Laszlo Almasi (almalaci)]

Thanks a lot lad for posting and attikon for compiling this all together.
I've been trying for a long-long time to get my network working after suspend. Finally it's working!!

[Alex (jelly)]

I followed attikon's instructions step by step (twice), but when I reboot, it doesn't work anymore, I have to do the manip' again (I'm on Ubuntu 8.10 Interpid).

I have no idea what could be the issue here...

[Alex (jelly)]

I take back what I've said... things seem ok...

[Kozie (flamefingers)]

On a fresh installed 8.10, i had the same problem. Tried the same with the msi=0 msix=0 but this didn't made any changes.

I decided to blame something else for this issue and so i started to search on my 'Message too large' problem, which i was getting when using 'dhclient eth0'.

To solve my problem, the answer was quite simple ^^

Edit: /etc/dhcp3/dhclient.conf

..and search for 'interface-mtu' (Without the quotes ofcourse. Comment this one out or disable it on your way. Reboot and prair ;)

This one worked for me

[1089 (k19-111)]

This problem is still relevant in Ubuntu 8.04 and Kubuntu 9.10. I am using an Asus P5N32E Sli Plus Motherboard and the networks refuse to work. I have to add an old networking card to access updates etc. Is there any chance of a permanent fix appearing?

[Black Sliver (andreas-lausch)]

I don't have the problem anymore. I've installed 9.10 a few days ago and everything on that mainboard (including Front Mic) worked right out of the box :)
Things I haven't tested yet are the surround output at the back as well as the 2nd network jack. I don't think there's any difference between them - eth0 works like a charm :)

[Bobinours (bobinours)]

Not as lucky as Black Silver, I still have this problem on Ubuntu 9.04 and 9.10 on a Asus P5N32-E SLI MotherBoard.
Hopefully the patch describe by "attikon (Ion)" is still working.

[docjones (jonesjerem)]

I am wondering if the patch described by "attikon (Ion)" is actually in fact still working in Ubuntu 9.10? Can someone confirm or deny..thanks.