On Thu, Feb 9, 2012 at 12:28 AM, Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: > 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. Not really. IIRC it might have some time, but not now. > 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? That's how I am running the kernel already. (I compiled v3.2 myself) -- Felipe Contreras -- 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
