Re: Udev coldplugging loads 8139too driver instead of 8139cp
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 wy 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? -- 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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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 wy 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. -- 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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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 ...v10ECd8139... 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
>> *v10ECd8139*)
>> 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/
>
>
>
--
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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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
> *v10ECd8139*)
> 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
--
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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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
*v10ECd8139*)
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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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
*v10ECd8139*)
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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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
*v10ECd8139*)
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
--
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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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 ...v10ECd8139... 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
*v10ECd8139*)
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/
--
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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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 wy 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. -- 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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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 wy 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? -- 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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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 :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip > > 8139too :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 wy 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]> -- 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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
Frederik Himpe wrote: > Linux 2.6.24 kernel gives the following messages when udev coldplugging > loads the driver for my NIC: > > 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip > 8139too :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 wy too late and will not help anyway) ;) /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/
Udev coldplugging loads 8139too driver instead of 8139cp
Linux 2.6.24 kernel gives the following messages when udev coldplugging loads the driver for my NIC: 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip 8139too :00:0b.0: Use the "8139cp" driver for improved performance and stability. ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10 ACPI: PCI Interrupt :00:0b.0[A] -> Link [LNK1] -> GSI 10 (level, low) -> IRQ 10 8139too :00:0b.0: unknown chip version, assuming RTL-8139 8139too :00:0b.0: TxConfig = 0x7480 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 :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- SERR- -- 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/
Udev coldplugging loads 8139too driver instead of 8139cp
Linux 2.6.24 kernel gives the following messages when udev coldplugging loads the driver for my NIC: 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip 8139too :00:0b.0: Use the 8139cp driver for improved performance and stability. ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10 ACPI: PCI Interrupt :00:0b.0[A] - Link [LNK1] - GSI 10 (level, low) - IRQ 10 8139too :00:0b.0: unknown chip version, assuming RTL-8139 8139too :00:0b.0: TxConfig = 0x7480 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 :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] -- 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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
Frederik Himpe wrote: Linux 2.6.24 kernel gives the following messages when udev coldplugging loads the driver for my NIC: 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip 8139too :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 wy too late and will not help anyway) ;) /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/
Re: Udev coldplugging loads 8139too driver instead of 8139cp
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 :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip 8139too :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 wy 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] -- 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/
