Red Hat Bugzilla – Bug 191048
tulip.ko dmfe.ko Davicom and DEC-Tulip compatible ethernet card modules mixed up
Last modified: 2007-11-30 17:11:32 EST
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.
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.
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.
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.
Created attachment 137459 [details] kernel BUG text.
Created attachment 137460 [details] Anotther BUG.
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.
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.
Is this related to bug 189942? I don't suppose you tried an NFS install on this hardware?
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.
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.
Created attachment 139482 [details] lspci -n -vvv from the system. ( The nic is 02:07.0 )
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.
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!