> Hello, > Your problem looks like Slawek's one: > > http://lists.freebsd.org/mailman/htdig/freebsd-current/2005-July/052785.html > > -- > * Wojciech A. Koszek && dunstan_at_FreeBSD.czest.pl > 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. 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. 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? -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul_at_windriver.com | Wind River Systems ============================================================================= <adamw> you're just BEGGING to face the moose =============================================================================Received on Mon Oct 24 2005 - 00:16:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:46 UTC