Bug 236928 - [dmfe:9102] tulip driver loads for dmfe network adapter
Summary: [dmfe:9102] tulip driver loads for dmfe network adapter
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 12
Hardware: All
OS: Linux
medium
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
URL:
Whiteboard:
: 446469 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-18 14:22 UTC by Fred New
Modified: 2010-04-27 14:31 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-04-27 14:31:20 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Fred New 2007-04-18 14:22:22 UTC
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.

Comment 1 Fred New 2007-05-04 06:01:19 UTC
I am no longer seeing this problem with kernel-2.6.21-1.3116.fc7.  Someone from
the kernel maintainers may close this bug.

Comment 2 Fred New 2007-05-28 07:42:17 UTC
This problem reappeared with FC7T4.  As soon as ifconfig shows RX errors, my
network access is dead.

Comment 3 Fred New 2007-06-13 08:41:22 UTC
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.

Comment 4 Fred New 2007-07-19 05:58:45 UTC
This problem is still present with the FC7 test kernel, kernel-2.6.22.1-27.fc7.

Comment 5 Chuck Ebbert 2007-09-20 19:27:33 UTC
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?


Comment 6 Fred New 2007-09-21 05:13:08 UTC
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)

Comment 7 Fred New 2007-09-25 11:13:31 UTC
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.

Comment 8 Fred New 2007-09-28 06:42:20 UTC
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.

Comment 9 Fred New 2007-10-01 08:35:31 UTC
This problem still present with kernel-2.6.22.9-91.fc7.

Comment 10 Chuck Ebbert 2007-10-01 21:12:25 UTC
Can you post the output of 'lspci -n'?

Comment 11 Fred New 2007-10-02 04:23:13 UTC
[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 ~]#

Comment 12 Chuck Ebbert 2007-10-02 21:07:33 UTC
A workaround is to blacklist the tulip driver. (Edit /etc/modprobe.d/blacklist
and add it to the list.)


Comment 13 Fred New 2008-04-02 07:40:04 UTC
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.

Comment 14 Bug Zapper 2008-05-14 02:46:42 UTC
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

Comment 15 Bug Zapper 2009-06-09 22:32:54 UTC
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

Comment 16 Fred New 2009-06-17 09:18:35 UTC
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.

Comment 17 Fred New 2009-11-18 12:21:10 UTC
This bug is still present in Fedora 12, but easy to work around.

Comment 18 Peter Lemenkov 2010-04-20 09:19:10 UTC
*** Bug 446469 has been marked as a duplicate of this bug. ***

Comment 19 Fred New 2010-04-22 09:58:40 UTC
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).

Comment 20 Chuck Ebbert 2010-04-27 14:31:20 UTC
Tulip support for the 910X is now only enabled on SPARC.


Note You need to log in before you can comment on or make changes to this bug.