Date: Sun, 23 Oct 2005 20:38:50 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: wpaul@freebsd.org Cc: slawek.zak@gmail.com, dunstan@freebsd.czest.pl, freebsd-current@freebsd.org Subject: Re: The case of the missing USB controllers Message-ID: <20051023.203850.56563508.imp@bsdimp.com> In-Reply-To: <20051024021606.5BB9D16A420@hub.freebsd.org> References: <20051023094907.GA37741@freebsd.czest.pl> <20051024021606.5BB9D16A420@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20051024021606.5BB9D16A420@hub.freebsd.org>
wpaul@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.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051023.203850.56563508.imp>