Description of problem:
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):
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.
Two modules try to handle the device, presumably the wrong one
thus networking with DHCP fails.
Single module is loaded, DHCP works.
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.
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
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
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
Created attachment 137459 [details]
kernel BUG text.
Created attachment 137460 [details]
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.
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
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
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
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