Hide Forgot
Description of problem: Since installing F7T3 I haven't been able to get one of my NICs to work. Lspci shows: 02:0a.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 31) I am not certain that this NIC was using the dmfe driver in F7T2. This may be an Anaconda driver-assignment problem. But it was working and it was the only NIC I used in T2. Now I have started using the e100 device on the motherboard. Current symptoms are that I can ping the gateway and the name server, but SSH to or from this system are unreliable. Ifconfig shows errors: $ /sbin/ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:80:AD:70:E6:FC inet addr:194.106.103.103 Bcast:194.106.103.127 Mask:255.255.255.224 inet6 addr: fe80::280:adff:fe70:e6fc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:185 errors:145 dropped:0 overruns:0 frame:0 TX packets:206 errors:13 dropped:0 overruns:0 carrier:13 collisions:0 txqueuelen:1000 RX bytes:18915 (18.4 KiB) TX bytes:31386 (30.6 KiB) Interrupt:20 Base address:0xe800 Version-Release number of selected component (if applicable): kernel-2.6.20-1.3079.fc7 How reproducible: always Steps to Reproduce: 1. Install F7T3 2. Try using the network. Actual results: It may or may not work. If SSH works, expect it to die within a few minutes. Expected results: Additional info: I have had this problem with all kernels in F7T3.
I am no longer seeing this problem with kernel-2.6.21-1.3116.fc7. Someone from the kernel maintainers may close this bug.
This problem reappeared with FC7T4. As soon as ifconfig shows RX errors, my network access is dead.
This problem is still present with FC7 (final) kernel 3194. I can bring up the interface for a few seconds, but as soon as ifconfig shows RX errors, the network is dead.
This problem is still present with the FC7 test kernel, kernel-2.6.22.1-27.fc7.
Does the tulip driver work better? # ifdown ethX # rmmod dmfe # modprobe tulip # ifup ethX And can you post the output of 'lspci -n' for that device?
This device is normally not running, so I first tried ifup with the dmfe driver. As usual, the device started, but "ifconfig eth0" showed some TX packet errors. And after about a minute the device stopped working and this event coincided with ifconfig showing RX errors. Next I tried the tulip driver using your instructions. It didn't work at all. After ifup eth0, ifconfig showed a lot of errors, TX and RX. However, putting the dmfe driver back: # ifdown eth0 # rmmod tulip # modprobe dmfe # ifup eth0 is running with 0 errors shown by ifconfig. I am going to configure my system to boot using eth0 for now. I imagine I will need to go through this same sequence to get eth0 working, but at least I won't have to play with the ethernet cable. :-) lspci -n: 02:0a.0 0200: 1282:9102 (rev 31) Current kernel = kernel-2.6.22.5-76.fc7 (i686 - Pentium 4, 2 GHz)
After some looking around, I found that both the dmfe and tulip drivers are loaded at boot time. I need to ifdown eth0 rmmod dmfe tulip modprobe dmfe ifup eth0 before eth0 starts working correctly. Only dmfe appears in /etc/modprobe.conf. My second NIC uses the e100 driver, so I don't think it affects this.
Testing more, I thought I would see if the tulip driver works for this device. It doesn't. Well, it works a little, but I couldn't establish an SSH session with it. Current kernel = kernel-2.6.22.7-85.fc7.
This problem still present with kernel-2.6.22.9-91.fc7.
Can you post the output of 'lspci -n'?
[root@ruuttest ~]# lspci -n 00:00.0 0600: 8086:2530 (rev 04) 00:01.0 0604: 8086:2532 (rev 04) 00:1e.0 0604: 8086:244e (rev 04) 00:1f.0 0601: 8086:2440 (rev 04) 00:1f.1 0101: 8086:244b (rev 04) 00:1f.2 0c03: 8086:2442 (rev 04) 00:1f.3 0c05: 8086:2443 (rev 04) 00:1f.5 0401: 8086:2445 (rev 04) 01:00.0 0300: 102b:2527 (rev 01) 02:01.0 0c03: 1033:0035 (rev 41) 02:01.1 0c03: 1033:0035 (rev 41) 02:01.2 0c03: 1033:00e0 (rev 02) 02:08.0 0200: 8086:2449 (rev 03) 02:0a.0 0200: 1282:9102 (rev 31) [root@ruuttest ~]#
A workaround is to blacklist the tulip driver. (Edit /etc/modprobe.d/blacklist and add it to the list.)
This bug is still present with rawhide kernel-2.6.25-0.177.rc7.git6.fc9.i686, but can be left at a low priority - workaround available.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This bug is still present in Fedora 11. I had to remove dmfe and tulip, then modprobe dmfe, during the installation process in order perform a network installation.
This bug is still present in Fedora 12, but easy to work around.
*** Bug 446469 has been marked as a duplicate of this bug. ***
This bug appears to be fixed in Fedora 13 (beta). With kernel-PAE-2.6.33.2-57.fc13.i686 the tulip driver didn't get loaded (and I didn't put anything in /etc/modprobe.d/ blacklist).
Tulip support for the 910X is now only enabled on SPARC.