Spurious short packet errors received because SHORT_NOT_OK flag is always turned on.

[cwn]

This bug was seen in libusb 1.0.9 running on Linux kernel 3.2.0. If the async bulk transfer is broken up into multiple URBs, then all but the last URB should have the SHORT_NO_OK flag turned on so that short USB packets in the middle of the transfer will be reported as an error. The bug is that the SHORT_NOT_OK flag is always turned on even if there is only one URBs in the transfer. This causes any URBs that ends in a short packet to return any -EREMOTEIO error. The result is that when a large number of 9206 byte async bulk transfers are queued a 300 to 400 microsecond delay can be seen on a USB protocol analyser between transfers.

Changing the if statement in libusb-1.0.9/libusb/os/linux_usbfs.c on line 1629 to check if the URB is the last URB in the transfer before turning on the SHORT_NOT_OK flag seems to have fixed the problem for me.

Original Code:

if (supports_flag_bulk_continuation && !is_out)

urb->flags = USBFS_URB_SHORT_NOT_OK;

Modified Code:

if (supports_flag_bulk_continuation && !is_out && i+1 != num_urbs)

urb->flags = USBFS_URB_SHORT_NOT_OK;

[stuge]

I think that this change makes sense. Could you create a commit against libusb.git and attach a patch to the ticket, or push it somewhere? A small style remark is that I think i < num_urbs-1 might be slightly more obvious.

[hjelmn]

If this change makes sense I am going to push for it to be included in 1.0.16. Any objections?