Re: [Libusbx-devel] usbdevfs: BULK_CONTINUATION flag does not work with XHCI controller
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Hi, On 05/25/2012 10:54 PM, Alan Stern wrote:
On Fri, 25 May 2012, Hans de Goede wrote:Hi, I spend the last 1.5 days debugging a problem with redirecting certain USB mass-storage devices to a Windows 7 vm. This problem only happens when the device is plugged into an USB 3 port. I believe I now know what is happening: First the working sequence: 1) Windows guest writes some bulk data to the msd 2) Windows guest tries to read up to 20480 bytes, only reads 36 bytes 3) Windows guest tries to read up to 512 bytes, only reads 13 bytes The non working sequence: 1) Windows guest writes some bulk data to the msd 2) Windows guest tries to read up to 20480 bytes, only reads 49 bytes 3) Windows guest tries to read up to 512 bytes -> timeout Here is what I believe is happening, at 2 libusb splits the bulk in transfer into 2 packets, 1 of 16k and 1 of 4k, setting the USBDEVFS_URB_SHORT_NOT_OK flag on both and the USBDEVFS_URB_BULK_CONTINUATION flag on the second. With the EHCI controller all then works as intended, the first packet transfers 36 bytes and returns a status of EREMOTEIO, the second packet gets cancelled by drivers/usb/core/devio.c, transferring 0 bytes and returns a status of ECONNRESET and we all live happily ever after :)That's the expected result.With the XHCI controller however, the first packet transfers 36 bytes and returns a status of EREMOTEIO, as it should, but the second packet transfers the 13 next bytes and returns a status of ECONNRESET.However that is wrong.IOW the second packet of the split bulk transfer reads more data despite the first packet returning an error status and the USBDEVFS_URB_BULK_CONTINUATION flag being set. Thus the second packets has consumed the data the device had ready which should have been read by the next bulk transfer from the guest pov. All in all it seems that the cancel of further packets done by drivers/usb/core/devio.c: cancel_bulk_urbs() comes too late when the device is on an XHCI controller, it seems that the controller is already "executing" the next bulk transfer *before* the completion handler of the previous one has completed.No, the cancellation doesn't come too late. Rather, the endpoint queue did not get stopped as it should when the EREMOTEIO error occurred.
Which leads to the conclusion that I believe that the BULK_CONTINUATION flag does not work properly with the XHCI controller.The flag is not presented to the host controller driver. It is handled entirely within devio.c.
I know, still it does not work with my xHCI controller :)
Regards, Hans p.s. To verify my theory, I've tried raising the packet splitting limit in libusb to 32k and that (unsurprisingly) fixes things, but that is just a bandaid and not a proper fix for the issue at hand IMHO. Also bulk packets> 32k only work with the latest kernels.Judging by your description, there is a bug either in xhci-hcd or in your xHCI hardware. What does "lspci -vv" show for the controller?
01:00.0 USB Controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04) (prog-if 30 [XHCI]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at fe600000 (64-bit, non-prefetchable) [size=8K] Capabilities: <access denied> Kernel driver in use: xhci_hcd But I don't believe this is hardware specific, I started investigating this after a bug report from a user of my USB redirection code, that user was seeing this with a thinkpad W510. I'll ask an lsusb -vv from him too, just in case that model has the exact same hardware. I'm thinking that maybe the issue is that the EREMOTEIO error gets generated by the driver based on the SHORT_NOT_OK flag (or so I believe), not the hc itself, could it be that the code doing that does not halt the ep, or halts it too late? Thanks & Regards, Hans -- 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
[Linux Media] [Video for Linux] [Linux Input] [Linux Audio Users] [Photo] [Yosemite News] [Yosemite Photos] [Free Online Dating] [Linux Kernel] [Linux SCSI] [Old Linux USB Devel Archive] [More Archives]