On Thu, Feb 9, 2012 at 10:02 AM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: > 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) Any update on this? Have you had time to look at the kernel log? Should I return this card? -- 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
