Hi, Gentle reminder. Any ideas about that log? On Thu, Feb 2, 2012 at 2:14 AM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > On Wed, Feb 1, 2012 at 6:51 PM, Sarah Sharp > <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: >> On Tue, Jan 31, 2012 at 10:52:42PM +0200, Felipe Contreras wrote: >>> On Tue, Jan 31, 2012 at 9:34 PM, Sarah Sharp >>> <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: >>> > On Tue, Jan 31, 2012 at 02:18:12PM +0200, Felipe Contreras wrote: >>> >> I'm contacting the support for the U34P card. Also, I will try to >>> >> update the firmware of the USB 3 device. >>> > >>> > I'm trying to figure out if there's a way to create a quirk for your >>> > card, to work around the bad extended capabilities. Can you capture >>> > dmesg, and plug and unplug a USB 2.0 device into each port? I'm looking >>> > for lines in the dmesg that say: >>> > >>> > Port Status Change Event for port X. >>> > >>> > That will let me know which port offsets the host controller thinks are >>> > USB 2.0 ports. >>> >>> Here it is: >>> http://people.freedesktop.org/~felipec/xhci/dmesg_3.txt.xz >> >> "You don't have permission to access /~felipec/xhci/dmesg_3.txt.xz on >> this server." > > Opps! Fixed. > >>> Note that this USB 2.0 device didn't work =/ >> >> BTW, I think I finally know why your host controller only lists one USB >> 2.0 port on the roothub. I recall that VIA made the decision to re-use >> one of their USB 2.0 hubs in their host controller. So the internal >> diagram of the host controller card actually looks something like this: >> >> xHCI roothub port status registers >> >> USB 2 USB 3 USB 3 USB 3 USB 3 >> port 1 port 2 port 3 port 4 port 5 >> ______________________________________________________________ >> | | | | | >> | | | | | >> ________________________________ | | | | >> VIA | | | | | >> USB 2 | | | | | >> hub | | | | | >> port 1 port2 port 3 port 4| | | | | >> ________________________________| | | | | >> | | | | | | | | >> | | | ________ | | | >> | | | physical | | | >> | | | port 1 | | | >> | | |_________________ | | | >> | | | | | | >> | | ______ | | >> | | physical | | >> | | port 2 | | >> | |__________________________________ | | >> | | | | >> | _______ | >> | physical | >> | port 3 | >> |___________________________________________________ | >> _______ >> physical >> port 4 >> >> From a user standpoint, you see four physical ports on the card that >> provide both USB 2.0 and USB 3.0 connections. Internally though, >> there's a USB 2.0 hub that's in between the four USB 2.0 port >> connections and the one USB 2.0 port register in the xHCI roothub. >> >> It's called a "tier-mismatch" in the xHCI spec. You can look at Figure >> 43 in section 4.24.2.3 for a non-ascii version of a tier mismatch: >> >> http://www.intel.com/technology/usb/download/xHCI_Specification_for_USB.pdf >> >> So that's why we saw the USB 2.0 hub get enumerated when you showed me >> the log of plugging in a USB 3.0 device. I thought it was a part of >> your USB 3.0 device, but it was actually part of the host controller. I >> think the USB 3.0 device just didn't link train with the host controller >> (in fact the host controller didn't even report it failed link >> training). > > I see, that makes sense. But what could case that error? > > Cheers. -- Felipe Contreras ��.n��������+%������w��{.n�����{���)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
