usbdevfs: BULK_CONTINUATION flag does not work with XHCI controller

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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.

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.

Which leads to the conclusion that I believe that the
BULK_CONTINUATION flag does not work properly with the 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.
--
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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux