On Fri, May 25, 2012 at 04:54:01PM -0400, Alan Stern wrote: > On Fri, 25 May 2012, Hans de Goede wrote: > > 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. Why would the xHCI endpoint queue get stopped after an EREMOTEIO error? The upper layers never clear a halt on a short bulk packet, so the xHCI driver has to restart the ring itself after a short packet. 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
