On Tue, May 8, 2012 at 9:05 PM, Sergio Correia <lists@xxxxxxxx> wrote: > Hello Sarah, > > On Tue, May 8, 2012 at 6:26 PM, Sarah Sharp > <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: >> On Tue, May 08, 2012 at 12:43:24PM -0400, Sergio Correia wrote: >>> Hi, >>> >>> On Tue, May 8, 2012 at 12:25 PM, Sarah Sharp >>> <sarah.a.sharp@xxxxxxxxxxxxxxx> wrote: >>> > On Tue, May 08, 2012 at 10:56:59AM -0400, Alan Stern wrote: >>> >> On Tue, 8 May 2012, Sergio Correia wrote: >>> >> >>> >> > the output from USBmon for both EHCI and xHCI is available at: >>> >> > http://www.uece.net/misc/usb-headset-problem/usbmon-usb2-bus2-dev6.txt >>> >> > http://www.uece.net/misc/usb-headset-problem/usbmon-usb3-bus3-dev5.txt >>> >> >>> >> It's notable that the bus-2 trace (which I presume is the one using >>> >> EHCI) shows that even though each packet requested 96 bytes of data, >>> >> the device sent only 88 or 90 bytes. By contrast, the bus-3 trace >>> >> (xHCI) shows that each packet contained 96 bytes. We should expect the >>> >> two traces not to differ in this way. >>> >> >>> >> This may be a bug in the xhci-hcd driver -- it may say it got more >>> >> bytes than actually were received. >>> > >>> > I actually suspect it might be a bug in the hardware itself. The lspci >>> > shows it's a very early Fresco Logic chipset revision, and it wouldn't >>> > surprise me if the xHCI host just doesn't report the short packet >>> > completion code. Let's rule that out before I go digging around the >>> > xHCI ring code (which looks like it's handling short packets properly, >>> > BTW). >>> > >>> > Sergio, can you apply the attached patch, and see if the host is >>> > actually reporting short packets? >>> >>> the dmesg is there: >>> http://www.uece.net/misc/usb-headset-problem/dmesg-short-packet-completion-code.bz2 >>> it was too large, so I bzip'ed it. >> >> Yeah, it looks like the Fresco Logic host controller is reporting a >> successful completion status, with an untransferred length of 8 bytes, >> which is a contradiction. Since we can tell from the EHCI logs that it >> actually should be reporting a short packet status, I think we should be >> able to just add a quirk for it, to trust the untransferred length. >> >> I wonder if this is just for short control transfers, or if they have >> this bug for other endpoint types? >> >> Please revert the last patch, apply the next patch, and see if the audio >> sounds any better. >> > > The compilation fails with the following error: > > drivers/usb/host/xhci-pci.c: In function ‘xhci_pci_quirks’: > drivers/usb/host/xhci-pci.c:75:19: error: ‘XHCI_CHECK_SUCCESS’ > undeclared (first use in this function) > drivers/usb/host/xhci-pci.c:75:19: note: each undeclared identifier is > reported only once for each function it appears in > make[3]: *** [drivers/usb/host/xhci-pci.o] Error 1 > make[2]: *** [drivers/usb/host] Error 2 > make[1]: *** [drivers/usb] Error 2 > make: *** [drivers] Error 2 > > I replaced with XHCI_TRUST_TX_LENGTH and it compiled fine. I am testing now and it seems to be working as well (audio sounds OK to me). The new usbmon trace is here: http://www.uece.net/misc/usb-headset-problem/usbmon-xhci-patch-applied.txt And here an audio sample with the patch applied: http://www.uece.net/misc/usb-headset-problem/test-usb3.0-patch-applied.mp3 thanks for your help! sergio >> How did you get access to this xHCI host controller? AFAIK, it was a >> short run chip that Fresco Logic did just for the USB-IF PDK, back in >> 2008. Is it an off-the-shelf add-in card, or integrated in some system? >> > > Ouch. It came with the ASUS N53SV-DH72 laptop I got this March. > > sergio > >> 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
