Re: [libusb] libusb Asynchronous Bulk Transfer Timeout On Linux Ubuntu

[Chris D. <chr...@gm...>]

An URB status of -2 means the transfer was successfully cancelled, meaning
it was still linked on the host controller and had not yet completed.

There are two things that could prevent the transfer from completing:

1) Bandwidth contention (unlikely if the timeout is sufficiently long)
2) The device isn't sending data back to the host when asked

As far as attempting to attach the kernel driver, I suspect that actually
fails with -EBUSY. A quick glance at the kernel code shows that if the
interface already has a driver bound it returns an error. In your case
claiming the interface causes the "usbfs" driver to be bound.

Chris

On Tue, Sep 12, 2017 at 3:11 PM, Ian Murtaugh <ian...@gm...>
wrote:

> David,
>
> Yes.  I have tried it both ways: reattaching the kernel driver and leaving
> it detached.  Neither approach changes the outcome unfortunately.
>
> Ian
>
> On Tue, Sep 12, 2017 at 3:36 PM, Ian Murtaugh <ian...@gm...>
> wrote:
>
>> I am using libusb on Ubuntu and am attempting to send 4 bytes of data via
>> an asynchronous bulk transfer. I am able to successfully perform the
>> following steps:
>>
>> Allocate the transfer via libusb_alloc_transfer.
>> Fill the bulk transfer via libusb_fill_bulk_transfer.
>> Detach the kernel driver via libusb_detach_kernel_driver.
>> Claim the interface via libusb_claim_interface.
>> Submit the transfer via libusb_submit_transfer.
>> Lastly, reattach the kernal driver via libusb_attach_kernel_driver.
>> The code will then run until the transfer times out and the callback
>> function is called. Enabling libusb debug provides the following messages:
>>
>> [10.033374] [000026fe] libusb: debug [handle_events] timerfd triggered
>> [10.033375] [000026fe] libusb: debug [libusb_cancel_transfer] transfer
>> 0x55555576de80
>> [10.036908] [000026fe] libusb: debug [disarm_timerfd]
>> [10.036919] [000026fe] libusb: debug [handle_events] poll() 3 fds with
>> timeout in 0ms
>> [10.036921] [000026fe] libusb: debug [handle_events] poll() returned 1
>> [10.036924] [000026fe] libusb: debug [reap_for_handle] urb type=3
>> status=-2 transferred=0
>> [10.036926] [000026fe] libusb: debug [handle_bulk_completion] handling
>> completion status -2 of bulk urb 1/1
>> [10.036927] [000026fe] libusb: debug [handle_bulk_completion] abnormal
>> reap: urb status -2
>> [10.036928] [000026fe] libusb: debug [handle_bulk_completion] abnormal
>> reap: last URB handled, reporting
>> [10.036930] [000026fe] libusb: debug [usbi_handle_transfer_cancellation]
>> detected timeout cancellation
>> [10.036931] [000026fe] libusb: debug [disarm_timerfd]
>> [10.036932] [000026fe] libusb: debug [usbi_handle_transfer_completion]
>> transfer 0x55555576de80 has callback 0x7ffff7bd4c78
>> Questions:
>>
>> What does a URB status of -2 mean?
>> Based on your knowledge or experience, what could possibly prevent the
>> transfer from actually taking place?
>>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>