pcnet32 devices with incorrect trident vendor ID

pcnet32 devices with incorrect trident vendor ID

[Daniel Drake]

Jon Mason wrote:
> Some pcnet32 hardware erroneously has the Vendor ID for Trident.  The
> pcnet32 driver looks for the PCI ethernet class before grabbing the
> hardware, but the current trident driver does not check against the
> PCI audio class.  This allows the trident driver to claim the pcnet32 
> hardware.  This patch prevents that.

On the subject of pcnet32 and the invalid vendor ID, you may find this 
interesting:

http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html

The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to 
2.6, it changed to Trident.

I guess this is still likely to be a hardware bug, but it demonstrates 
that the Linux PCI layer has something to do with it (even if it is just 
triggering it somehow).

Daniel

Re: pcnet32 devices with incorrect trident vendor ID

[Matthew Wilcox]

On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> interesting:
> 
> http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
> 
> The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to 
> 2.6, it changed to Trident.

It looks to me like there used to be a quirk that knew about this bug
and fixed it.

The reason I say this is that the lspci -x dumps are the same -- both
featuring the wrong vendor ID.  Want to dig through 2.4 and look for
this quirk?

Re: pcnet32 devices with incorrect trident vendor ID

[Daniel Drake]

Matthew Wilcox wrote:
> It looks to me like there used to be a quirk that knew about this bug
> and fixed it.
> 
> The reason I say this is that the lspci -x dumps are the same -- both
> featuring the wrong vendor ID.

Good catch. I didn't notice this.

 > Want to dig through 2.4 and look for
> this quirk?

No time for this personally.

Daniel

Re: pcnet32 devices with incorrect trident vendor ID

[Lennart Sorensen]

On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> On the subject of pcnet32 and the invalid vendor ID, you may find this 
> interesting:
> 
> http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
> 
> The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to 
> 2.6, it changed to Trident.
> 
> I guess this is still likely to be a hardware bug, but it demonstrates 
> that the Linux PCI layer has something to do with it (even if it is just 
> triggering it somehow).

Perhaps there is a significant different in the pcnet32.c files between
the two versions.  I also remember that there is some powerpc specific
code in there related to MAC address detection.  There are certainly
differences in 2.4 and 2.6's version of the driver, maybe something is
broken in the newer one when run on powerpc.  I don't run gentoo and
have no idea how to get a hold of the source of pcnet32.c from each of
those two.

It does seem odd that only the pcnet32 has the pci ID change, but at the
same time, somehow the driver is recognizing it and loading at boot
time, so the ID can't be wrong at that time.  Does the ID get mangled as
part of what makes the MAC addresses read incorrectly on your 2.6.14?
The 2.4 system shows all the cards overriding the MAC based on the PROM,
which I believe is what the driver code should do on a powerpc system.
On 2.6 that appears to only happen on one of the cards.  At least on
that device (pci 01:01) appears to agree what the MAC should be in both
cases.

Perhaps the lspci being wrong is just a side effect of the real problem.
Maybe the driver is broken and messing things up.

Len Sorensen

Re: pcnet32 devices with incorrect trident vendor ID

[Matthew Wilcox]

On Thu, Jan 12, 2006 at 01:57:14PM -0700, Matthew Wilcox wrote:
> On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> > interesting:
> > 
> > http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
> > 
> > The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to 
> > 2.6, it changed to Trident.
> 
> It looks to me like there used to be a quirk that knew about this bug
> and fixed it.
> 
> The reason I say this is that the lspci -x dumps are the same -- both
> featuring the wrong vendor ID.  Want to dig through 2.4 and look for
> this quirk?

Oh -- found it.  It's still in 2.6:

static void
fixup_broken_pcnet32(struct pci_dev* dev)
{
        if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
                dev->vendor = PCI_VENDOR_ID_AMD;
                pci_write_config_word(dev, PCI_VENDOR_ID, PCI_VENDOR_ID_AMD);
        }
}
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TRIDENT, PCI_ANY_ID,                     
fixup_broken_pcnet32);

Wonder why it isn't working now ... someone with a PPC box needs to check
(a) whether this function is being called and (b) if it is called, why
it's not doing what it's supposed to.

Re: pcnet32 devices with incorrect trident vendor ID

[Bill Nottingham]

Matthew Wilcox (matthew@wil.cx) said: 
> On Thu, Jan 12, 2006 at 01:57:14PM -0700, Matthew Wilcox wrote:
> > On Thu, Jan 12, 2006 at 08:49:42PM +0000, Daniel Drake wrote:
> > > interesting:
> > > 
> > > http://forums.gentoo.org/viewtopic-t-420013-highlight-trident.html
> > > 
> > > The user saw the correct vendor ID (AMD) in 2.4, but when upgrading to 
> > > 2.6, it changed to Trident.
> > 
> > It looks to me like there used to be a quirk that knew about this bug
> > and fixed it.
> > 
> > The reason I say this is that the lspci -x dumps are the same -- both
> > featuring the wrong vendor ID.  Want to dig through 2.4 and look for
> > this quirk?
> 
> Oh -- found it.  It's still in 2.6:
> 
> static void
> fixup_broken_pcnet32(struct pci_dev* dev)
> {
>         if ((dev->class>>8 == PCI_CLASS_NETWORK_ETHERNET)) {
>                 dev->vendor = PCI_VENDOR_ID_AMD;
>                 pci_write_config_word(dev, PCI_VENDOR_ID, PCI_VENDOR_ID_AMD);
>         }
> }
> DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TRIDENT, PCI_ANY_ID,                     
> fixup_broken_pcnet32);
> 
> Wonder why it isn't working now ... someone with a PPC box needs to check
> (a) whether this function is being called and (b) if it is called, why
> it's not doing what it's supposed to.

I remember looking at this a while back. I think the corrected information
is only being propagated to the 'vendor' file, and the write_config_word
isn't actually updating the 'config' entry in sysfs.

If you remove the "#if 0" from lib/sysfs.c in pciutils, it should
start reporting the corrected value in base lspci, etc.

Bill

Re: pcnet32 devices with incorrect trident vendor ID

[Bill Nottingham]

Bill Nottingham (notting@redhat.com) said: 
> I remember looking at this a while back. I think the corrected information
> is only being propagated to the 'vendor' file, and the write_config_word
> isn't actually updating the 'config' entry in sysfs.

Ah, here's an example from the box I remember working on this on
(without the libpci change):

root@pseries 0000:00:0c.0]# pwd
/sys/bus/pci/devices/0000:00:0c.0
[root@pseries 0000:00:0c.0]# lspci | grep 0c.0
00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
[root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
00:0c.0 Class 0200: 1023:2000 (rev 26)
[root@pseries 0000:00:0c.0]# cat vendor
0x1022
[root@pseries 0000:00:0c.0]# cat device
0x2000
[root@pseries 0000:00:0c.0]# od -x config
0000000 2310 0020 4701 8002 2600 0002 0048 0000
0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
0000040 0000 0000 0000 0000 0000 0000 0000 0000
0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
0000100 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400

Note that the config space is different than the vendor file. This
was with 2.6.9-ish, I don't have the box around any more to confirm
with something more recent.

Bill

Re: pcnet32 devices with incorrect trident vendor ID

[Don Fry]

There are just a few differences between the 2.4 (1.30h) version of
pcnet32.c and the 2.6 (1.30j) version, as I have tried to keep them
as similar as possible.

The driver was changed in February 2004 to recognize the incorrect
vendor ID so that the ppc workaround was no longer required, and so that
the cards would work in non ppc systems.  From the driver perspective
the ppc workaround could be deleted.

On my systems lspci shows all the devices with the correct name whether
it is ppc or x86.

PPC:
donf@elm3b48:/usr/src> lspci | grep Ethernet
0000:01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 54)
0000:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
0000:62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0000:62:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0001:21:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44)
0001:31:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
0001:41:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
0001:61:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
donf@elm3b48:/usr/src>

x86:
[donf@elm3b45 linux-2.6.14-git11]$ lspci | grep Ethernet
00:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
02:06.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 36)
05:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
05:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
05:04.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
[donf@elm3b45 linux-2.6.14-git11]$ 

On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote:
> Bill Nottingham (notting@redhat.com) said: 
> > I remember looking at this a while back. I think the corrected information
> > is only being propagated to the 'vendor' file, and the write_config_word
> > isn't actually updating the 'config' entry in sysfs.
> 
> Ah, here's an example from the box I remember working on this on
> (without the libpci change):
> 
> root@pseries 0000:00:0c.0]# pwd
> /sys/bus/pci/devices/0000:00:0c.0
> [root@pseries 0000:00:0c.0]# lspci | grep 0c.0
> 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
> [root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
> 00:0c.0 Class 0200: 1023:2000 (rev 26)
> [root@pseries 0000:00:0c.0]# cat vendor
> 0x1022
> [root@pseries 0000:00:0c.0]# cat device
> 0x2000
> [root@pseries 0000:00:0c.0]# od -x config
> 0000000 2310 0020 4701 8002 2600 0002 0048 0000
> 0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
> 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> 0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
> 0000100 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000400
> 
> Note that the config space is different than the vendor file. This
> was with 2.6.9-ish, I don't have the box around any more to confirm
> with something more recent.
> 
> Bill
-- 
Don Fry
brazilnut@us.ibm.com

Re: pcnet32 devices with incorrect trident vendor ID

[Jon Mason]

On Thu, Jan 12, 2006 at 02:23:20PM -0800, Don Fry wrote:
> There are just a few differences between the 2.4 (1.30h) version of
> pcnet32.c and the 2.6 (1.30j) version, as I have tried to keep them
> as similar as possible.
> 
> The driver was changed in February 2004 to recognize the incorrect
> vendor ID so that the ppc workaround was no longer required, and so that
> the cards would work in non ppc systems.  From the driver perspective
> the ppc workaround could be deleted.
> 
> On my systems lspci shows all the devices with the correct name whether
> it is ppc or x86.

Funny, I get the following on my opteron system:

# lspci | grep Ethernet
0000:03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02)
0000:0e:01.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)

> 
> PPC:
> donf@elm3b48:/usr/src> lspci | grep Ethernet
> 0000:01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 54)
> 0000:21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d)
> 0000:62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0000:62:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0001:21:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44)
> 0001:31:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26)
> 0001:41:01.0 Ethernet controller: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) (rev 01)
> 0001:61:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
> donf@elm3b48:/usr/src>
> 
> x86:
> [donf@elm3b45 linux-2.6.14-git11]$ lspci | grep Ethernet
> 00:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
> 00:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
> 02:05.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 16)
> 02:06.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 36)
> 05:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 44)
> 05:03.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet LANCE] (rev 54)
> 05:04.0 Ethernet controller: Advanced Micro Devices [AMD] 79c978 [HomePNA] (rev 51)
> [donf@elm3b45 linux-2.6.14-git11]$ 
> 
> On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote:
> > Bill Nottingham (notting@redhat.com) said: 
> > > I remember looking at this a while back. I think the corrected information
> > > is only being propagated to the 'vendor' file, and the write_config_word
> > > isn't actually updating the 'config' entry in sysfs.
> > 
> > Ah, here's an example from the box I remember working on this on
> > (without the libpci change):
> > 
> > root@pseries 0000:00:0c.0]# pwd
> > /sys/bus/pci/devices/0000:00:0c.0
> > [root@pseries 0000:00:0c.0]# lspci | grep 0c.0
> > 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26)
> > [root@pseries 0000:00:0c.0]# lspci -n | grep 0c.0
> > 00:0c.0 Class 0200: 1023:2000 (rev 26)
> > [root@pseries 0000:00:0c.0]# cat vendor
> > 0x1022
> > [root@pseries 0000:00:0c.0]# cat device
> > 0x2000
> > [root@pseries 0000:00:0c.0]# od -x config
> > 0000000 2310 0020 4701 8002 2600 0002 0048 0000
> > 0000020 01f0 ff00 0070 21c3 0000 0000 0000 0000
> > 0000040 0000 0000 0000 0000 0000 0000 0000 0000
> > 0000060 0000 10c3 0000 0000 0000 0000 1101 06ff
> > 0000100 0000 0000 0000 0000 0000 0000 0000 0000
> > *
> > 0000400
> > 
> > Note that the config space is different than the vendor file. This
> > was with 2.6.9-ish, I don't have the box around any more to confirm
> > with something more recent.
> > 
> > Bill
> -- 
> Don Fry
> brazilnut@us.ibm.com
>