Linux 2.6.24 kernel gives the following messages when udev coldplugging
loads the driver for my NIC:
8139too 0000:00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip
8139too 0000:00:0b.0: Use the "8139cp" driver for improved performance and stability.
ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10
8139too 0000:00:0b.0: unknown chip version, assuming RTL-8139
8139too 0000:00:0b.0: TxConfig = 0x74800000
eth1: RealTek RTL8139 at 0xcee8e800, 00:08:02:d8:d5:b9, IRQ 10
eth1: Identified 8139 chip type 'RTL-8139'
ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:13.2[C] -> Link [LNK3] -> GSI 11 (level, low) -> IRQ 11
Output of lspci -vvvn:
00:0b.0 0200: 10ec:8139 (rev 20)
Subsystem: 0e11:0056
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at 9000 [size=256]
Region 1: Memory at f0018800 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: 8139too
Kernel modules: 8139cp, 8139too
Why does not udev coldpluggin first try to load 8139cp instead of
8139too?
--
Frederik Himpe <[email protected]>
Frederik Himpe wrote:
> Linux 2.6.24 kernel gives the following messages when udev coldplugging
> loads the driver for my NIC:
>
> 8139too 0000:00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip
> 8139too 0000:00:0b.0: Use the "8139cp" driver for improved performance and stability.
There are 2 drivers for 8139-based NICs. For really different two kinds
of hardware, which both uses the same PCI identifiers. Both drivers
"claims" to work with all NICs with those PCI ids, because "externally"
(by means of udev for example) it's impossible to distinguish the two
kinds of hardware, it becomes clean only when the driver (either of the
two) loads and actually checks which hardware we have here.
Udev in fact loads both - 8139cp and 8139too. The difference is the ORDER
in which it loads them - if for "cp-handled" hardware it first loads "too",
too will complain as above and will NOT claim the device. The same is
true for the opposite.
So - in short - things has always been this way (thanks to realtec).
I've seen similar (but opposite) effects on my systems, which are all
should be serviced by 8139too driver but 8139cp loaded first - up
till i gave up and just disabled 8139cp...
I don't know what happened in 2.6.24, but my guess is that since 8139too-based
hw is now alot more common, the two drivers are listed in the opposite
order.
In short: NotABug, or ComplainToRealtec (but that's waaaay too late and
will not help anyway) ;)
/mjt
On Tue, 29 Jan 2008 03:46:08 +0300
Michael Tokarev <[email protected]> wrote:
> Frederik Himpe wrote:
> > Linux 2.6.24 kernel gives the following messages when udev coldplugging
> > loads the driver for my NIC:
> >
> > 8139too 0000:00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip
> > 8139too 0000:00:0b.0: Use the "8139cp" driver for improved performance and stability.
>
> There are 2 drivers for 8139-based NICs. For really different two kinds
> of hardware, which both uses the same PCI identifiers. Both drivers
> "claims" to work with all NICs with those PCI ids, because "externally"
> (by means of udev for example) it's impossible to distinguish the two
> kinds of hardware, it becomes clean only when the driver (either of the
> two) loads and actually checks which hardware we have here.
Is there any chance of using subdevice or subversion to tell them apart?
That worked for other vendors like DLINK who slapped same ID on different
cards.
> Udev in fact loads both - 8139cp and 8139too. The difference is the ORDER
> in which it loads them - if for "cp-handled" hardware it first loads "too",
> too will complain as above and will NOT claim the device. The same is
> true for the opposite.
>
> So - in short - things has always been this way (thanks to realtec).
> I've seen similar (but opposite) effects on my systems, which are all
> should be serviced by 8139too driver but 8139cp loaded first - up
> till i gave up and just disabled 8139cp...
>
> I don't know what happened in 2.6.24, but my guess is that since 8139too-based
> hw is now alot more common, the two drivers are listed in the opposite
> order.
>
> In short: NotABug, or ComplainToRealtec (but that's waaaay too late and
> will not help anyway) ;)
>
> /mjt
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Stephen Hemminger <[email protected]>
Stephen Hemminger wrote:
> On Tue, 29 Jan 2008 03:46:08 +0300
> Michael Tokarev <[email protected]> wrote:
[]
>> There are 2 drivers for 8139-based NICs. For really different two kinds
>> of hardware, which both uses the same PCI identifiers. Both drivers
>> "claims" to work with all NICs with those PCI ids, because "externally"
>> (by means of udev for example) it's impossible to distinguish the two
>> kinds of hardware, it becomes clean only when the driver (either of the
>> two) loads and actually checks which hardware we have here.
>
> Is there any chance of using subdevice or subversion to tell them apart?
> That worked for other vendors like DLINK who slapped same ID on different
> cards.
If it were that simple... ;)
No. The difference is in PCI revision number (byte #8 in PCI config space).
If it's >= 0x40 - it's 8139too, < 0x40 - 8139cp. Or 0x20 - I forgot.
Here's a code snippet from a shell script I used ages ago to automatically
load modules (similar to what udev does nowadays):
# special hack for 8139{too,cp} stuff
case "$modalias" in
*v000010ECd00008139*)
rev="$(dd if="$1/config" bs=1 skip=8 count=1 2>/dev/null)"
if [ -n "$rev" ]; then
list=
for module in $modlist; do
case "$module" in
8139cp)
if [ ".$rev" \< ". " ]; then
$vecho1 "$TAG: not loading $module for this device"
continue
fi
;;
8139too)
if [ ".$rev" \> ". " ]; then
$vecho1 "$TAG: not loading $module for this device"
continue
fi
;;
esac
list="$list $module"
done
modlist="$list"
fi
;;
esac
/mjt
On Tuesday 29 January 2008 11:43:53 Michael Tokarev wrote:
> Stephen Hemminger wrote:
> > On Tue, 29 Jan 2008 03:46:08 +0300
> > Michael Tokarev <[email protected]> wrote:
>
> []
>
> >> There are 2 drivers for 8139-based NICs. For really different two kinds
> >> of hardware, which both uses the same PCI identifiers. Both drivers
> >> "claims" to work with all NICs with those PCI ids, because "externally"
> >> (by means of udev for example) it's impossible to distinguish the two
> >> kinds of hardware, it becomes clean only when the driver (either of the
> >> two) loads and actually checks which hardware we have here.
> >
> > Is there any chance of using subdevice or subversion to tell them apart?
> > That worked for other vendors like DLINK who slapped same ID on different
> > cards.
>
> If it were that simple... ;)
>
> No. The difference is in PCI revision number (byte #8 in PCI config
> space). If it's >= 0x40 - it's 8139too, < 0x40 - 8139cp. Or 0x20 - I
> forgot.
Perhaps a module could be created that will claim this device ID and then use
the correct driver.
> Here's a code snippet from a shell script I used ages ago to automatically
> load modules (similar to what udev does nowadays):
>
> # special hack for 8139{too,cp} stuff
> case "$modalias" in
> *v000010ECd00008139*)
> rev="$(dd if="$1/config" bs=1 skip=8 count=1 2>/dev/null)"
> if [ -n "$rev" ]; then
> list=
> for module in $modlist; do
> case "$module" in
> 8139cp)
> if [ ".$rev" \< ". " ]; then
> $vecho1 "$TAG: not loading $module for this device"
> continue
> fi
> ;;
> 8139too)
> if [ ".$rev" \> ". " ]; then
> $vecho1 "$TAG: not loading $module for this device"
> continue
> fi
> ;;
> esac
> list="$list $module"
> done
> modlist="$list"
> fi
> ;;
> esac
>
> /mjt
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Ondrej Zary
Ondrej Zary wrote:
> On Tuesday 29 January 2008 11:43:53 Michael Tokarev wrote:
>> Stephen Hemminger wrote:
>> > On Tue, 29 Jan 2008 03:46:08 +0300
>> > Michael Tokarev <[email protected]> wrote:
>>
>> []
>>
>> >> There are 2 drivers for 8139-based NICs. For really different two
>> >> kinds
>> >> of hardware, which both uses the same PCI identifiers. Both drivers
>> >> "claims" to work with all NICs with those PCI ids, because
>> >> "externally" (by means of udev for example) it's impossible to
>> >> distinguish the two kinds of hardware, it becomes clean only when the
>> >> driver (either of the two) loads and actually checks which hardware we
>> >> have here.
>> >
>> > Is there any chance of using subdevice or subversion to tell them
>> > apart? That worked for other vendors like DLINK who slapped same ID on
>> > different cards.
>>
>> If it were that simple... ;)
>>
>> No. The difference is in PCI revision number (byte #8 in PCI config
>> space). If it's >= 0x40 - it's 8139too, < 0x40 - 8139cp. Or 0x20 - I
>> forgot.
>
> Perhaps a module could be created that will claim this device ID and then
> use the correct driver.
>
C'mon, really ...
echo 'alias ...v000010ECd00008139... 8139too' >> /etc/modprobe.conf
>> Here's a code snippet from a shell script I used ages ago to
>> automatically load modules (similar to what udev does nowadays):
>>
>> # special hack for 8139{too,cp} stuff
>> case "$modalias" in
>> *v000010ECd00008139*)
>> rev="$(dd if="$1/config" bs=1 skip=8 count=1 2>/dev/null)"
>> if [ -n "$rev" ]; then
>> list=
>> for module in $modlist; do
>> case "$module" in
>> 8139cp)
>> if [ ".$rev" \< ". " ]; then
>> $vecho1 "$TAG: not loading $module for this device"
>> continue
>> fi
>> ;;
>> 8139too)
>> if [ ".$rev" \> ". " ]; then
>> $vecho1 "$TAG: not loading $module for this device"
>> continue
>> fi
>> ;;
>> esac
>> list="$list $module"
>> done
>> modlist="$list"
>> fi
>> ;;
>> esac
>>
>> /mjt
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
>> in the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
On Tue, 2008-01-29 at 03:46 +0300, Michael Tokarev wrote:
> Udev in fact loads both - 8139cp and 8139too. The difference is the ORDER
> in which it loads them - if for "cp-handled" hardware it first loads "too",
> too will complain as above and will NOT claim the device. The same is
> true for the opposite.
Actually, it's the order in which the probe functions run, which is
typically related to the order in which they are loaded. You can
blacklist one driver and get the other instead.
> I don't know what happened in 2.6.24, but my guess is that since 8139too-based
> hw is now alot more common, the two drivers are listed in the opposite
> order.
Nah. Random build ordering as it always has been - two different builds
would end up with modules in a different order on disk, hence depmod
would generate a different ordering. This will be fixed shortly with the
Modules.order bits, but you will still need to blacklist one of the
drivers (unless you're lucky and 8139too comes first), until there is
proper support for dynamic rebinding and udev rules to do that.
> In short: NotABug, or ComplainToRealtec (but that's waaaay too late and
> will not help anyway) ;)
Nah. It's a "bug" insomuch as we don't handle multiple matching aliases
very well, and it's becoming more common, so we probably should :)
Jon.
On Jan 29 2008 18:34, Jon Masters wrote:
>On Tue, 2008-01-29 at 03:46 +0300, Michael Tokarev wrote:
>
>> Udev in fact loads both - 8139cp and 8139too. The difference is the ORDER
>> in which it loads them - if for "cp-handled" hardware it first loads "too",
>> too will complain as above and will NOT claim the device. The same is
>> true for the opposite.
>[...]
>> In short: NotABug, or ComplainToRealtec (but that's waaaay too late and
>> will not help anyway) ;)
>
>Nah. It's a "bug" insomuch as we don't handle multiple matching aliases
>very well, and it's becoming more common, so we probably should :)
Why not combine 8139cp.c and 8139too.c?