nVidia 680i Ethernet is not working / Forcedeth Module

Bug #117411 reported by redabour
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned
linux-restricted-modules-2.6.20 (Ubuntu)
Won't Fix
Undecided
Unassigned
linux-source-2.6.20 (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

Hi,

i found the Solution but you should know that this has be fixed for the next Release/Update :

http://www.nvnews.net/vbulletin/showthread.php?s=f1f0ac7f89f9d0eca610c0d53bc61d0f&t=79917&page=2&highlight=680i+ethernet

Revision history for this message
redabour (andre-mondri-freenet) wrote :

Try the following:

* Check if forcedeth-Module is available in your config:
Code:

modprobe -l | grep forcedeth Should result in something like (other kernel number): /lib/modules/2.6.18-4-686/kernel/drivers/net/forcedeth.ko

* Check if forcedeth-Module is currently active:
Code:

lsmod | grep forcedeth if active, it should result in forcedeth 38372 0

* Unload forcedeth-Module if active
Code:

modprobe -r forcedeth

* Load forcedeth-Module without MSI and MSIX for testing:
Code:

modprobe forcedeth msi=0 msix=0

* Restart Network:
Code:

/etc/init.d/networking restart

* If your ethernet is now working, you can update your module-configuration like described in the previous posts to process the forcedeth-options on system boot.

Revision history for this message
redabour (andre-mondri-freenet) wrote :

Anyone else with this Problem?

Revision history for this message
redabour (andre-mondri-freenet) wrote :

Shit - tried it again and found out that the Solution above does not work.

Cards are found - configured - but the Connection is still dead.

I cant post Attachments here neither because ntfs is not writable to bringt Logs from Linux to the Windows i write now from.

Only thing i can do is to move fixed Files from my Windowspartition to Linux if there was any fix.

Any Suggestions ?

Revision history for this message
jcfp (jcfp) wrote :

Changing package since forcedeth module is not in restricted: linux-restricted-modules-2.6.20 -> linux-source-2.6.20

Please add the following additional information to this bug report:
 1. The output of the command "uname -a". It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
 2. Please run the command "dmesg > dmesg.log" and attach the resulting file "dmesg.log" to this bug report.
 3. Please run the command "lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

Revision history for this message
redabour (andre-mondri-freenet) wrote :

I cant attach any File because i cant get any Internetconnection or NTFS write access to move it to Windows and attach it here.

It is the 32bit Standard Ubuntukernel after fresh Installation from a normal 32bit Ubuntukernel on a nVidia 680i Chipset.

Revision history for this message
DaveAbrahams (boostpro) wrote :

I've been having the problem, ever since upgrading my server to feisty, that the ethernet simply disappears at seemingly random times of high activity and won't come back until after a reboot. I've tried

  modprobe forcedeth msi=0 msix=0

as suggested in the thread, but I don't yet know whether that will make a difference. I agree that if this is in fact the cause of the problem, it is urgetn to backport an updated driver and/or at least arrange for an update that patches /etc/modules.conf

Revision history for this message
DaveAbrahams (boostpro) wrote :

Update: no, that didn't work for me. I'll attach the requested info for my system.

uname -a: Linux hydra 2.6.20-16-generic #2 SMP Sun Sep 23 18:31:23 UTC 2007 x86_64 GNU/Linux

Revision history for this message
Francesco Conti (arunax165) wrote :

I can confirm both the existence of this problem in Hardy Alpha 5 and the fact that the solution posted above still works. In Gutsy forcedeth worked out-of-the-box, so I think this bug should be fixed (especially because Hardy is LTS)

Revision history for this message
Luis Fernando Teixeira (lf-ubuntu) wrote :

I am using Hardy Heron (release), the problem persists.

Revision history for this message
Luis Fernando Teixeira (lf-ubuntu) wrote :

I tried the solution of adding "options forcedeth msi=0 msix=0" to (both) "/etc/modprobe.conf" and "/etc/modprobe.d/options", and it partially works, i.e., it works after I manually execute:

sudo modprobe -r forcedeth
sudo modprobe forcedeth

after I log in...

For a "beginners" workaround, I already have made a script to do this trick, and installed an icon on a panel, which executes "gksudo /home/<USERNAME>/Scripts/restartForcedeth.sh" (the script is attached - don't forget inserting the options!!!). Just put it in a "Scripts" directory in your home, make it executable, and create the launcher... Dirty but works - hope someone finds it useful... I'll still try to find a better solution...

I think that this is a critical problem (at least for everyone that has an nForce chipset), because internet connectivity is almost required nowadays, and it is very frustrating for a new user of Ubuntu to have to cope with this kind of problem.

Revision history for this message
Luis Fernando Teixeira (lf-ubuntu) wrote :

I have succeeded in using an expect script to automate user and password passing to enable execution of the modprobes... Sadly I think that this is unsecure, since it requires that the password be in clear on the script... Anyone there knows the trick to "restart" the forcedeth without requiring passwords?

I also found that on my wife´s notebook I have to "restart" the b43 module for the network to function properly. Is it common the need for these restarts in network drivers/modules?

Revision history for this message
Luis Fernando Teixeira (lf-ubuntu) wrote :

It seems that the problem with my wife's notebook is not related to this one. I don't need anymore to "restart" the b43 module for it to work, just put the network in roaming. Sorry for the "white noise"...

Revision history for this message
Luis Fernando Teixeira (lf-ubuntu) wrote :

After the recent kernel upgrade (from 2.6.24.16.18 to 2.6.24.17.19), the problem is fixed. I don't have to use the dirty trick above anymore. Thanks a lot!!!

Revision history for this message
Luis Fernando Teixeira (lf-ubuntu) wrote :

Complete log of the updates:

Commit Log for Tue May 27 19:23:53 2008

Upgraded the following packages:
apport (0.108.1) to 0.108.2
apport-gtk (0.108.1) to 0.108.2
gdm (2.20.6-0ubuntu1) to 2.20.6-0ubuntu2
gnome-keyring (2.22.1-1) to 2.22.1-1ubuntu1
libgnome-keyring0 (2.22.1-1) to 2.22.1-1ubuntu1
libpam-gnome-keyring (2.22.1-1) to 2.22.1-1ubuntu1
linux-generic (2.6.24.16.18) to 2.6.24.17.19
linux-headers-generic (2.6.24.16.18) to 2.6.24.17.19
linux-image-generic (2.6.24.16.18) to 2.6.24.17.19
linux-restricted-modules-common (2.6.24.12-16.34) to 2.6.24.12-17.36
linux-restricted-modules-generic (2.6.24.16.18) to 2.6.24.17.19
nvidia-glx-new (169.12+2.6.24.12-16.34) to 169.12+2.6.24.12-17.36
python-apport (0.108.1) to 0.108.2
python-problem-report (0.108.1) to 0.108.2

Installed the following packages:
linux-headers-2.6.24-17 (2.6.24-17.31)
linux-headers-2.6.24-17-generic (2.6.24-17.31)
linux-image-2.6.24-17-generic (2.6.24-17.31)
linux-restricted-modules-2.6.24-17-generic (2.6.24.12-17.36)
linux-ubuntu-modules-2.6.24-17-generic (2.6.24-17.25)

Revision history for this message
Launchpad Janitor (janitor) wrote : This bug is now reported against the 'linux' package

Beginning with the Hardy Heron 8.04 development cycle, all open Ubuntu kernel bugs need to be reported against the "linux" kernel package. We are automatically migrating this bug to the new "linux" package. However, development has already began for the upcoming Intrepid Ibex 8.10 release. It would be helpful if you could test the upcoming release and verify if this is still an issue - http://www.ubuntu.com/testing . If the issue still exists, please update this report by changing the Status of the "linux" task from "Incomplete" to "New". We appreciate your patience and understanding as we make this transition. Thanks!

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

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.

Revision history for this message
Bryce Harrington (bryce) wrote : linux-restricted-modules-2.6.20 is obsolete

This package has become obsolete so we're closing out the bug report as WONTFIX.
Thanks for reporting it though!

Changed in linux-restricted-modules-2.6.20:
status: New → Won't Fix
Changed in linux:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.