Red Hat Bugzilla – Bug 157783
8139cp not working for all 10ec:8139 devices
Last modified: 2014-03-16 22:53:54 EDT
Description of problem:
8139cp: 10/100 PCI Ethernet driver v1.2 (Mar 22, 2004)
8139cp: pci dev 0000:06:00.0 (id 10ec:8139 rev 10) is not an 8139C+ compatible chip
8139cp: Try the "8139too" driver instead.
8139cp gets loaded by hotplug because it claims support for vendor 10ec device 8139.
[root@laptop ~]# /sbin/modinfo 8139cp
author: Jeff Garzik <firstname.lastname@example.org>
description: RealTek RTL-8139C+ series 10/100 PCI Ethernet driver
parm: debug:8139cp: bitmapped message enable number
parm: multicast_filter_limit:8139cp: maximum number of filtered
vermagic: 2.6.11-1.1303_FC4 686 REGPARM 4KSTACKS gcc-4.0
kudzu will use 8139too instead (according to /usr/share/hwdata/pcitable)
So the question is, does 8139too support all 10ec:8139 devices? Then support
from 8139cp could be removed.
There is an overlap between the devices supported by the 8139cp and 8139too
drivers. This overlap cannot be resolved simply by looking at PCI IDs,
although considering PCI revisions may prove useful. I'm reassigning to the
developer responsible for hotplug.
kudzu does the right thing with these devices. The kernel needs to not export
duplicate PCI ids in general.
"8139cp gets loaded by hotplug... kudzu will use 8139too instead"
So, I guess comment 3 is correct, if irrelevant... :-)
Once again, reassigning to _hotplug_...
hotplug modprobes an alias consisting of vendor and device id.
And modprobe loads the first module which fits.
I think the best place for the information which module is responsible for which
devices is best located in the kernel.
kudzu simply overrides the information from the kernel (really a duplicate effort)
"The kernel needs to not export
duplicate PCI ids in general."
Given the mess vendors do with pci ids, it maybe better if modprobe loads all
modules, not only the first.
The problem is that there is no information exported for the kernel on a hotplug
event to pick the correct device generally, and adding special code into the
hotplug path for one driver just seems silly.
The kernel *already* does the same thing with things like i8xx_tco and tpm_XXX;
so userspace can at best pick one module with the current hotplug infrastructure
as implemented by the kernel.
FWIW, something has replaced 8139too with 8139cp in my /etc/modprobe.conf,
breaking eth0 on my AMD64 notebook. I can't quite figure out what it is, but it
sure is bogus. From the time the file was modified, it looks like it wasn't an
rpm script, but rather something done at boot time, that didn't affect that
boot, only subsequent boots. Is kudzu to blame? Should this be filed there?
FWIW, even though eth0 is now correctly aliased back to 8139too, and eth0 works
again, something still loads the 8139cp module. hotplug?
02:01.0 Class 0200: 10ec:8139 (rev 10)
02:01.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: Hewlett-Packard Company: Unknown device 006b
Flags: bus master, medium devsel, latency 64, IRQ 185
I/O ports at 7000 [size=256]
Memory at e0106800 (32-bit, non-prefetchable) [size=256]
Capabilities:  Power Management version 2
In the devel tree, a hotplug event for PCMCIA/Cardbus will load both modules, as
they both match the alias on hotplugging. Only one should actually claim the
A fix for the accidental reconfiguration should be in kudzu-1.1.122-1.
This should be solved in FC5 and the FC6 devel tree.