Bug 191048

Summary: tulip.ko dmfe.ko Davicom and DEC-Tulip compatible ethernet card modules mixed up
Product: [Fedora] Fedora Reporter: Jasper O. Hartline <jasperhartline>
Component: kernelAssignee: Neil Horman <nhorman>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: davej, linville, oggust, steve30401, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-08 19:51:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
kernel BUG text.
none
Anotther BUG.
none
lspci -n -vvv from the system. none

Description Jasper O. Hartline 2006-05-08 14:07:57 UTC
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):
2.6.16-1.2111_FC5smp

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.
2. 
3.
  
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 192.168.2.3 up
route add default gw 192.168.2.1
---
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.
Thanks.

Comment 1 Stephen Sentoff 2006-05-21 15:30:18 UTC
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
ifconfig.

Comment 2 Jasper O. Hartline 2006-05-21 16:42:01 UTC
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-30 01:33:12 UTC
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-30 01:37:59 UTC
Created attachment 137459 [details]
kernel BUG text.

Comment 5 Björn Augustsson 2006-09-30 01:39:05 UTC
Created attachment 137460 [details]
Anotther BUG.

Comment 6 Dave Jones 2006-10-16 19:54:10 UTC
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 23:01:39 UTC
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 13:25:21 UTC
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 13:34:16 UTC
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 16:28:53 UTC
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 16:42:39 UTC
Created attachment 139482 [details]
lspci -n -vvv from the system.

( The nic is 02:07.0 )

Comment 12 Neil Horman 2006-11-20 19:32:01 UTC
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 19:47:28 UTC
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

Thanks!