Re: pcnet32 devices with incorrect trident vendor ID

[lsorense@csclub.uwaterloo.ca (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
-
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/