In message: <20051024021606.5BB9D16A420_at_hub.freebsd.org> wpaul_at_freebsd.org (Bill Paul) writes: : Well, after some investigation and experimentation, I came up with the : following patch for src/sys/dev/pci/pci.c which seems to fix the problem, : at least on my machine: : : http://www.freebsd.org/~wpaul/opteron/pci.c.diff : : I'm not entirely sure why this works, but it does. The pci_add_children() : routine traverses each PCI bus by trying to read the header type field : at offset 0x0e. It does this for each possible slot number from 0 to 31. : A value of 0xFF indicates a failure to read the PCI config space at a : given slot number, which usually means there's no device there. Usually, but not always. : Unfortunately, it appears that sometimes it gets back 0xFF when trying : to read the header type field for the USB controllers (which are actually : three function at a single device index), even though the device is : really there. Then chances are there's something else wrong. You also get 0xff when you have a child device of pci bridge whose bus/secbus/subbus is setup wrong. I have some patches cooking to solve this problem that some people are seeing on some laptops. When it returns 0xff, that should be > the 2, and we should ignore the device... It looks like what you are saying that if you read the vendor ID then the header type wil read back correctly? Is that the case? : I rummaged around a bit and found the OpenSolaris source code that : enumerates PCI buses, and that code uses a slightly different algorithm: : for each slot number, it first tries to read the PCI vendor ID field. : If that value is valid, then it tries to read the header type field. : The patch above implements the Solaris behavior and seems to allow : FreeBSD/amd64 to detect the USB ports reliably. (I've rebooted the : system a bunch of times and so far it's been successful.) : : Logically, this should not have any negative impact in any other cases. : Can someone else who has this problem test this patch and tell me if it : helps? Can anyone think of a reason why this patch shouldn't be checked : in? Yes. We went through a lot of consternation with some PCI ethernet cards made by sun. They have 0xffff listed as the function 0 vendor, but the header type was correct. The ethernet lived in function 1. You change will break those. We used to implement what you suggested, but purposely changed it away from that. WarnerReceived on Mon Oct 24 2005 - 00:40:01 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC