LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Udev coldplugging loads 8139too driver instead of 8139cp
@ 2008-01-28 21:16 Frederik Himpe
  2008-01-29  0:46 ` Michael Tokarev
  0 siblings, 1 reply; 8+ messages in thread
From: Frederik Himpe @ 2008-01-28 21:16 UTC (permalink / raw)
  To: LKML, netdev

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 <fhimpe@telenet.be>


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Udev coldplugging loads 8139too driver instead of 8139cp
  2008-01-28 21:16 Udev coldplugging loads 8139too driver instead of 8139cp Frederik Himpe
@ 2008-01-29  0:46 ` Michael Tokarev
  2008-01-29  1:08   ` Stephen Hemminger
  2008-01-29 23:34   ` Jon Masters
  0 siblings, 2 replies; 8+ messages in thread
From: Michael Tokarev @ 2008-01-29  0:46 UTC (permalink / raw)
  To: Frederik Himpe; +Cc: LKML, netdev

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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Udev coldplugging loads 8139too driver instead of 8139cp
  2008-01-29  0:46 ` Michael Tokarev
@ 2008-01-29  1:08   ` Stephen Hemminger
  2008-01-29 10:43     ` Michael Tokarev
  2008-01-29 23:34   ` Jon Masters
  1 sibling, 1 reply; 8+ messages in thread
From: Stephen Hemminger @ 2008-01-29  1:08 UTC (permalink / raw)
  To: Michael Tokarev; +Cc: netdev, linux-kernel

On Tue, 29 Jan 2008 03:46:08 +0300
Michael Tokarev <mjt@tls.msk.ru> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Stephen Hemminger <stephen.hemminger@vyatta.com>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Udev coldplugging loads 8139too driver instead of 8139cp
  2008-01-29  1:08   ` Stephen Hemminger
@ 2008-01-29 10:43     ` Michael Tokarev
  2008-01-29 16:53       ` Ondrej Zary
  0 siblings, 1 reply; 8+ messages in thread
From: Michael Tokarev @ 2008-01-29 10:43 UTC (permalink / raw)
  To: Stephen Hemminger; +Cc: netdev, linux-kernel

Stephen Hemminger wrote:
> On Tue, 29 Jan 2008 03:46:08 +0300
> Michael Tokarev <mjt@tls.msk.ru> 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Udev coldplugging loads 8139too driver instead of 8139cp
  2008-01-29 10:43     ` Michael Tokarev
@ 2008-01-29 16:53       ` Ondrej Zary
  2008-01-29 18:18         ` Andrey Borzenkov
  0 siblings, 1 reply; 8+ messages in thread
From: Ondrej Zary @ 2008-01-29 16:53 UTC (permalink / raw)
  To: Michael Tokarev; +Cc: Stephen Hemminger, netdev, linux-kernel

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 <mjt@tls.msk.ru> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/



-- 
Ondrej Zary

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Udev coldplugging loads 8139too driver instead of 8139cp
  2008-01-29 16:53       ` Ondrej Zary
@ 2008-01-29 18:18         ` Andrey Borzenkov
  0 siblings, 0 replies; 8+ messages in thread
From: Andrey Borzenkov @ 2008-01-29 18:18 UTC (permalink / raw)
  To: Ondrej Zary, linux-kernel

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 <mjt@tls.msk.ru> 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 majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 
> 



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Udev coldplugging loads 8139too driver instead of 8139cp
  2008-01-29  0:46 ` Michael Tokarev
  2008-01-29  1:08   ` Stephen Hemminger
@ 2008-01-29 23:34   ` Jon Masters
  2008-01-29 23:37     ` Jan Engelhardt
  1 sibling, 1 reply; 8+ messages in thread
From: Jon Masters @ 2008-01-29 23:34 UTC (permalink / raw)
  To: Michael Tokarev; +Cc: Frederik Himpe, LKML, netdev


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.



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Udev coldplugging loads 8139too driver instead of 8139cp
  2008-01-29 23:34   ` Jon Masters
@ 2008-01-29 23:37     ` Jan Engelhardt
  0 siblings, 0 replies; 8+ messages in thread
From: Jan Engelhardt @ 2008-01-29 23:37 UTC (permalink / raw)
  To: Jon Masters; +Cc: Michael Tokarev, Frederik Himpe, LKML, netdev


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?

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-01-29 23:37 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-28 21:16 Udev coldplugging loads 8139too driver instead of 8139cp Frederik Himpe
2008-01-29  0:46 ` Michael Tokarev
2008-01-29  1:08   ` Stephen Hemminger
2008-01-29 10:43     ` Michael Tokarev
2008-01-29 16:53       ` Ondrej Zary
2008-01-29 18:18         ` Andrey Borzenkov
2008-01-29 23:34   ` Jon Masters
2008-01-29 23:37     ` Jan Engelhardt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).