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 > 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
