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 +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
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
