Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157783 - 8139cp not working for all 10ec:8139 devices
Summary: 8139cp not working for all 10ec:8139 devices
Alias: None
Product: Fedora
Classification: Fedora
Component: hotplug
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-15 12:17 UTC by Ronny Buchmann
Modified: 2014-03-17 02:53 UTC (History)
6 users (show)

Fixed In Version: FC5
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-09-25 18:47:06 UTC

Attachments (Terms of Use)

Description Ronny Buchmann 2005-05-15 12:17:06 UTC
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 <>
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.

Comment 2 John W. Linville 2005-05-18 17:32:47 UTC
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. 

Comment 3 Bill Nottingham 2005-05-18 18:13:42 UTC
kudzu does the right thing with these devices. The kernel needs to not export
duplicate PCI ids in general.

Comment 5 John W. Linville 2005-05-27 17:01:08 UTC
"8139cp gets loaded by hotplug... kudzu will use 8139too instead"  
So, I guess comment 3 is correct, if irrelevant... :-)  
Once again, reassigning to _hotplug_... 

Comment 6 Ronny Buchmann 2005-05-27 17:27:42 UTC
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.

Comment 7 Bill Nottingham 2005-05-27 18:34:00 UTC
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.

Comment 8 Alexandre Oliva 2005-08-29 01:07:41 UTC
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

Comment 9 Bill Nottingham 2005-08-29 01:54:21 UTC
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.

Comment 10 Bill Nottingham 2005-08-30 17:51:17 UTC
A fix for the accidental reconfiguration should be in kudzu-1.1.122-1.

Comment 11 Bill Nottingham 2006-09-25 18:47:06 UTC
This should be solved in FC5 and the FC6 devel tree.

Comment 12 Bill Nottingham 2006-09-25 19:14:19 UTC
This should be solved in FC5 and the FC6 devel tree.

Note You need to log in before you can comment on or make changes to this bug.