On Thu, Feb 02, 2012 at 02:14:20AM +0200, Felipe Contreras 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 =/ Yep, I see that the host controller doesn't like some input we gave it when we tried to set up the configuration endpoint rings: Jan 31 22:43:53 dyfed kernel: [ 79.045933] xhci_hcd 0000:02:00.0: ERROR: unexpected command completion code 0x11. Jan 31 22:43:53 dyfed kernel: [ 79.045935] xhci_hcd 0000:02:00.0: xhci_reset_bandwidth called for udev ffff88042bec7000 Jan 31 22:43:53 dyfed kernel: [ 79.045936] xhci_hcd 0000:02:00.0: Freeing ring at ffff880429dceae0 Jan 31 22:43:53 dyfed kernel: [ 79.045937] xhci_hcd 0000:02:00.0: Freeing DMA segment at ffff88000282b800 (virtual) 0x282b800 (DMA) Jan 31 22:43:53 dyfed kernel: [ 79.045939] xhci_hcd 0000:02:00.0: Freeing priv segment structure at ffff88042bee91c0 Jan 31 22:43:53 dyfed kernel: [ 79.045943] xhci_hcd 0000:02:00.0: Freeing ring at ffff880429dce060 Jan 31 22:43:53 dyfed kernel: [ 79.045944] xhci_hcd 0000:02:00.0: Freeing DMA segment at ffff880002843000 (virtual) 0x2843000 (DMA) Jan 31 22:43:53 dyfed kernel: [ 79.045946] xhci_hcd 0000:02:00.0: Freeing priv segment structure at ffff88042bee9fe0 I'll have to look at the input and see what we're doing wrong. > > 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? Maybe there's some other port status change bit set on the USB 3.0 port and we're not getting a connect status change event because of that? Does it help to run lsusb when you have the USB 3.0 device attached? If so, please send dmesg for that. The only other thing I can think of is to try compiling your kernel with CONFIG_USB_SUSPEND turned off. Maybe the host controller can't cope with the USB 3.0 port being suspended? Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
