Bug 191048 - tulip.ko dmfe.ko Davicom and DEC-Tulip compatible ethernet card modules mixed up
tulip.ko dmfe.ko Davicom and DEC-Tulip compatible ethernet card modules mixed up
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Neil Horman
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2006-05-08 10:07 EDT by Jasper O. Hartline
Modified: 2007-11-30 17:11 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-08 15:51:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
kernel BUG text. (5.30 KB, text/plain)
2006-09-29 21:37 EDT, Björn Augustsson
no flags Details
Anotther BUG. (3.45 KB, text/plain)
2006-09-29 21:39 EDT, Björn Augustsson
no flags Details
lspci -n -vvv from the system. (7.05 KB, application/octet-stream)
2006-10-26 12:42 EDT, Björn Augustsson
no flags Details

  None (edit)
Description Jasper O. Hartline 2006-05-08 10:07:57 EDT
Description of problem:
Using a:
00:0d.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip
compatible 10/100 Ethernet (rev 40)

ethernet card without doing anything off-key tulip.ko and dmfe.ko load to take
over control of the device. This causes network DHCP requests to fail.

This is a cheap $20 10/100 MBPS ethernet card picked up anywhere.
C-Net brand PRO200 ethernet card.

Version-Release number of selected component (if applicable):

How reproducible:
Let Anaconda probe and detect settings, even network installs fail.
Using noprobe with Anaconda it asks twice to configure an ethernet device once
into the installer about to contact a mirror.

Steps to Reproduce:
1. Install with named card with chipset above.
Actual results:
Two modules try to handle the device, presumably the wrong one
thus networking with DHCP fails.

Expected results:
Single module is loaded, DHCP works.

Additional info:
The fix for this I have been using is to unload with modprobe
both tulip and dmfe. Set a static address and hand crafted route.
The modprobe.conf file has alias eth0 dmfe yet using ifup or ifdown
cause tulip to get loaded also, which I do believe is not correct.
Although it is tulip compatible as lspci says, the network is up and
functioning properly without error with just dmfe.ko loaded.

This seems to work 100% of the time, unload both modules, set static interface
addresses and set the route. Here is the /etc/rc.d/rc.local snippet that works:
modprobe -r dmfe
modprobe -r tulip
ifconfig eth0 up
route add default gw
Any additional info can be provided, I'm imagining it is probably some familiar
code between the two modules and chipsets in fact, ones which use Tulip.
Comment 1 Stephen Sentoff 2006-05-21 11:30:18 EDT
I've run into this same problem.  My card is a "GFC1216C-TX-50".  This worked
with Fedora 3, using the dmfe driver.  My workaround was to add the following
into modprobe.conf, to eliminate the tulip driver:
install tulip /sbin/modprobe dmfe; /sbin/modprobe --ignore-install tulip

Now the network runs reliably, without the many packet errors I was seeing with
Comment 2 Jasper O. Hartline 2006-05-21 12:42:01 EDT
Surely this and the dmfe drivers can be merged.
The chips must be similar enough this can be done, why not is beyond me.

If anyone is interested I would bet this is a better idea than to leave them as
seperate entities.
Comment 3 Björn Augustsson 2006-09-29 21:33:12 EDT
I just upgraded from FC4 to FC5 and ran into this.

If I morprobe -r both dmfe and tulip, and then modprobe dmfe, everything works.

But if I remove them both, and then load tulip, the kernel BUGs. I did it twice
and it happened both times so it seems reasonably repeatable. I'll attach the
BUG texts.

Comment 4 Björn Augustsson 2006-09-29 21:37:59 EDT
Created attachment 137459 [details]
kernel BUG text.
Comment 5 Björn Augustsson 2006-09-29 21:39:05 EDT
Created attachment 137460 [details]
Anotther BUG.
Comment 6 Dave Jones 2006-10-16 15:54:10 EDT
A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.
Comment 7 Björn Augustsson 2006-10-22 19:01:39 EDT
Still happens in 2.6.18-1.2200.fc5.

Didn't test if the kernel crashes like before, but both drivers still get 
loaded, and the ethernet doesn't work until I modprobe -r both, and then 
load dmfe.

The temporary fix for me is to rm -f tulip.ko. (Works until the next
kernel upgrade) That makes unattended booting possible.
Comment 8 John W. Linville 2006-10-24 09:25:21 EDT
Is this related to bug 189942?  I don't suppose you tried an NFS install on 
this hardware?
Comment 9 Björn Augustsson 2006-10-24 09:34:16 EDT
Yeah, it's probably the same bug. (Same hardware, same results, seems likely.)

I did a "normal" yum upgrade FC4->FC5, and noticed that the network didn't
work afterwards.
Comment 10 Neil Horman 2006-10-26 12:28:53 EDT
Sounds like we need either to merge the drivers, or set some more specifics for
each drivers hardware support in their pci tables and in hwdata for
anaconda/kudzu.  lspci -n -vvv output would be helpful from the affected system
please. I'll look to see if we have hardware here for use in merging the drivers. 
Comment 11 Björn Augustsson 2006-10-26 12:42:39 EDT
Created attachment 139482 [details]
lspci -n -vvv from the system.

( The nic is 02:07.0 )
Comment 12 Neil Horman 2006-11-20 14:32:01 EST
yep, both tulip and dmfe support pci device id 0x1282 and vendor id 0x9102.  I'm
not sure of the ultimate solution here yet (if any change is really even
required), but I would suggest that you simply add tulip to
/etc/hotplug/blacklist for the time being, and make sure that it doesn't appear
in your /etc/modprobe.conf, since your lspci seems to indicate that you don't
have any tulip hardware at the moment.
Comment 13 Neil Horman 2006-11-20 14:47:28 EST
Ok, I've been talking about it, and the consensus is that tulip really should
work with this card.  While my comments in #12 are valid, and you can workaround
this long term with that fix, I'd appreciate it if you could
1) unload dmfe
2) set your syslog to catch KERN_DEBUG messages
3) load tulip.ko with tulip_debug set as a module option
4) try to bring up the network
5) send in the resultant /var/log/message file


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