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 filename: /lib/modules/2.6.11-1.1303_FC4/kernel/drivers/net/8139cp.ko author: Jeff Garzik <jgarzik> description: RealTek RTL-8139C+ series 10/100 PCI Ethernet driver license: GPL parmtype: debug:i parm: debug:8139cp: bitmapped message enable number parmtype: multicast_filter_limit:i parm: multicast_filter_limit:8139cp: maximum number of filtered multicast addresses vermagic: 2.6.11-1.1303_FC4 686 REGPARM 4KSTACKS gcc-4.0 depends: mii alias: pci:v000010ECd00008139sv*sd*bc*sc*i* alias: pci:v00000357d0000000Asv*sd*bc*sc*i* srcversion: 37E1DEC8FAA527874AF90DD 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." +1 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: [50] 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 card, though.
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.