Re: [Libusb-devel] Large receive buffer size causes an error?

[Adam N. <a.n...@sh...>]

> It goes wrong right away. 121 means a bus error. Actually there are
> some fairly significant fixes for bulk on Linux in libusb-stuge.git -
> could I ask you to try that also?

Sure, here's the output from libusb-stuge.git.  Looks pretty similar.  Note 
that I did change something else in the code which I think has resulted in a 
slightly different buffer size, but the failure still occurs for the same reason.

libusb:debug [submit_bulk_transfer] need 330 urbs for new transfer with length 
5400000
libusb:error [submit_bulk_transfer] submiturb failed error -1 errno=121
libusb:debug [libusb_submit_transfer] arm timerfd for timeout in 1500ms (first 
in line)
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-121 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -121 of bulk 
urb 1/330
libusb:debug [handle_bulk_completion] abnormal reap: urb status -121
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -104 of bulk 
urb 2/330
libusb:debug [handle_bulk_completion] abnormal reap: urb status -104
libusb:debug [handle_events] poll() 3 fds with timeout in 60000ms
libusb:debug [handle_events] poll() returned 1
libusb:debug [reap_for_handle] urb type=3 status=-104 transferred=0
libusb:debug [handle_bulk_completion] handling completion status -104 of bulk 
urb 3/330

> And it would be interesting to see usbmon output from when you run
> this. See Documentation/usb/usbmon.txt in the kernel source for
> instructions.

Here is the usbmon output narrowed down to just this call - please advise if 
you need any earlier output - there's a lot of it thanks to firmware uploads etc.

ffff880027efbe00 1899543261 S Bi:065:02 -115 16384 <
ffff88014030b8c0 1899543297 S Bi:065:02 -115 16384 <
ffff8800350a2600 1899543327 S Bi:065:02 -115 16384 <
ffff880128d7d380 1899543359 S Bi:065:02 -115 16384 <
.
.
.
ffff8800276c5d40 1899544828 S Bi:065:02 -115 16384 <
ffff880052d06ec0 1899544916 S Bi:065:02 -115 16384 <
ffff880052d06680 1899545006 S Bi:065:02 -115 16384 <
ffff880052d06980 1899545112 S Bi:065:02 -115 16384 <
ffff880027efbe00 1899545149 C Bi:065:02 -121 0
ffff88014030b8c0 1899545255 C Bi:065:02 -104 0
ffff8800350a2600 1899545317 C Bi:065:02 -104 0
ffff880128d7d380 1899545374 C Bi:065:02 -104 0
ffff88010cc9d980 1899545442 C Bi:065:02 -104 0
.
.
.
ffff8800276c5d40 1899548320 C Bi:065:02 -104 0
ffff880052d06ec0 1899548466 C Bi:065:02 -104 0
ffff880052d06680 1899548610 C Bi:065:02 -104 0
ffff880052d06980 1899548665 C Bi:065:02 -104 0

I also got this as the -121 response in the middle on an earlier run with 
libusb-pbatard.git:

ffff8801103c1e40 1422146944 C Bi:065:02 -121 4098 = 0d010800 00000000 00000000 
0006010c 322e2e4b 47494a2f 2e4b474a 492f2e4b

Cheers,
Adam.