Description of problem:
Since installing F7T3 I haven't been able to get one of my NICs to work. Lspci
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:18.104.22.168 Bcast:22.214.171.124 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
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):
Steps to Reproduce:
1. Install F7T3
2. Try using the network.
It may or may not work. If SSH works, expect it to die within a few minutes.
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-126.96.36.199-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. :-)
02:0a.0 0200: 1282:9102 (rev 31)
Current kernel = kernel-188.8.131.52-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
rmmod dmfe tulip
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
Current kernel = kernel-184.108.40.206-85.fc7.
This problem still present with kernel-220.127.116.11-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)
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:
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:
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
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.