https://bugzilla.novell.com/show_bug.cgi?id=559697
https://bugzilla.novell.com/show_bug.cgi?id=559697#c54
Stanislav Brabec changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEEDINFO
InfoProvider| |oneukum@suse.com
--- Comment #54 from Stanislav Brabec 2014-09-01 14:50:52 CEST ---
Re-checking status of this bug. However the bug itself is obsolete, the problem
can re-appear anywhere else.
According to the upstream (comment 24), the bug was caused by kernel.
Oliver, could you confirm, that in current kernels "given an example of 3 16kb
bulk URBs submitted in parallel, if the first one ends early then the other 2
will be immediately cancelled with no possibility for data to arrive in them,
as if they had never been submitted"?
Reference: http://sourceforge.net/p/libusb/mailman/message/24185174/
If the (first) request in sequence returns short transfer, is there any chance
that continuation URBs return any data?
Original problem in short:
libusb0:
If the bulk read request size > MAX_USBFS_BUFFER_SIZE, it submits URBs
sequentially. In case of short read, no more URBs are requested.
libusb1:
If the bulk read request size > MAX_USBFS_BUFFER_SIZE, it splits the transfer
to URBs and request them in parallel, using USBFS_URB_SHORT_NOT_OK and
USBFS_URB_BULK_CONTINUATION, where appropriate. It has a code handling
EREMOTEIO for short transfers (they will concatenate all returned data and
return them to user).
The bug reported here is apparently caused by a coincidence of several things:
* The driver attempts to guess scan line size by the amount of data returned:
It fails, if continuation request returned next scanline and libusb0
concatenated both. It confuses the driver.
* Sometimes it happens that amount of data to read and amount of data returned
differ by less than <256 bytes.
* Firmware bug that caused scanner to hang if URB is <256 bytes is submitted.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.