pcnet32 devices with incorrect trident vendor ID
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 - 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
Re: pcnet32 devices with incorrect trident vendor ID
On Thu, Jan 12, 2006 at 08:49:42PM +, 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? - 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
Re: pcnet32 devices with incorrect trident vendor ID
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 - 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
Re: pcnet32 devices with incorrect trident vendor ID
On Thu, Jan 12, 2006 at 08:49:42PM +, 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 - 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
Re: pcnet32 devices with incorrect trident vendor ID
On Thu, Jan 12, 2006 at 01:57:14PM -0700, Matthew Wilcox wrote:
> On Thu, Jan 12, 2006 at 08:49:42PM +, 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.
-
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
Re: pcnet32 devices with incorrect trident vendor ID
Matthew Wilcox ([EMAIL PROTECTED]) said:
> On Thu, Jan 12, 2006 at 01:57:14PM -0700, Matthew Wilcox wrote:
> > On Thu, Jan 12, 2006 at 08:49:42PM +, 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
-
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
Re: pcnet32 devices with incorrect trident vendor ID
Bill Nottingham ([EMAIL PROTECTED]) 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): [EMAIL PROTECTED] :00:0c.0]# pwd /sys/bus/pci/devices/:00:0c.0 [EMAIL PROTECTED] :00:0c.0]# lspci | grep 0c.0 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26) [EMAIL PROTECTED] :00:0c.0]# lspci -n | grep 0c.0 00:0c.0 Class 0200: 1023:2000 (rev 26) [EMAIL PROTECTED] :00:0c.0]# cat vendor 0x1022 [EMAIL PROTECTED] :00:0c.0]# cat device 0x2000 [EMAIL PROTECTED] :00:0c.0]# od -x config 000 2310 0020 4701 8002 2600 0002 0048 020 01f0 ff00 0070 21c3 040 060 10c3 1101 06ff 100 * 400 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 - 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
Re: pcnet32 devices with incorrect trident vendor ID
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: [EMAIL PROTECTED]:/usr/src> lspci | grep Ethernet :01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 54) :21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 0d) :62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26) :62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26) :62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 26) :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) [EMAIL PROTECTED]:/usr/src> x86: [EMAIL PROTECTED] 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) [EMAIL PROTECTED] linux-2.6.14-git11]$ On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote: > Bill Nottingham ([EMAIL PROTECTED]) 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): > > [EMAIL PROTECTED] :00:0c.0]# pwd > /sys/bus/pci/devices/:00:0c.0 > [EMAIL PROTECTED] :00:0c.0]# lspci | grep 0c.0 > 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26) > [EMAIL PROTECTED] :00:0c.0]# lspci -n | grep 0c.0 > 00:0c.0 Class 0200: 1023:2000 (rev 26) > [EMAIL PROTECTED] :00:0c.0]# cat vendor > 0x1022 > [EMAIL PROTECTED] :00:0c.0]# cat device > 0x2000 > [EMAIL PROTECTED] :00:0c.0]# od -x config > 000 2310 0020 4701 8002 2600 0002 0048 > 020 01f0 ff00 0070 21c3 > 040 > 060 10c3 1101 06ff > 100 > * > 400 > > 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 [EMAIL PROTECTED] - 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
Re: pcnet32 devices with incorrect trident vendor ID
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 :03:02.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit Ethernet (rev 02) :0e:01.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26) > > PPC: > [EMAIL PROTECTED]:/usr/src> lspci | grep Ethernet > :01:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 > [PCnet32 LANCE] (rev 54) > :21:01.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro > 100] (rev 0d) > :62:00.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 > [PCnet32 LANCE] (rev 26) > :62:01.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 > [PCnet32 LANCE] (rev 26) > :62:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 > [PCnet32 LANCE] (rev 26) > :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) > [EMAIL PROTECTED]:/usr/src> > > x86: > [EMAIL PROTECTED] 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) > [EMAIL PROTECTED] linux-2.6.14-git11]$ > > On Thu, Jan 12, 2006 at 04:24:35PM -0500, Bill Nottingham wrote: > > Bill Nottingham ([EMAIL PROTECTED]) 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): > > > > [EMAIL PROTECTED] :00:0c.0]# pwd > > /sys/bus/pci/devices/:00:0c.0 > > [EMAIL PROTECTED] :00:0c.0]# lspci | grep 0c.0 > > 00:0c.0 Ethernet controller: Trident Microsystems 4DWave DX (rev 26) > > [EMAIL PROTECTED] :00:0c.0]# lspci -n | grep 0c.0 > > 00:0c.0 Class 0200: 1023:2000 (rev 26) > > [EMAIL PROTECTED] :00:0c.0]# cat vendor > > 0x1022 > > [EMAIL PROTECTED] :00:0c.0]# cat device > > 0x2000 > > [EMAIL PROTECTED] :00:0c.0]# od -x config > > 000 2310 0020 4701 8002 2600 0002 0048 > > 020 01f0 ff00 0070 21c3 > > 040 > > 060 10c3 1101 06ff > > 100 > > * > > 400 > > > > 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 > [EMAIL PROTECTED] > - 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
