USB transfers stuck in kernel/libusb not sent out until next transfer is submitted

[Peer Stritzinger]

On Fri, Oct 19, 2012 at 11:51 AM, Hans Petter Selasky
<hans.petter.selasky at bitfrost.no> wrote:
>
> I see you are using 8.0 and I think that doesn't have usbdump.

Yep unfortunately.

> Try fetching libusb sources from 8-stable and just make the stream open
> routine return a failure, if it doesn't build.

Ok, I'll try.

> Yes, there has been some issues fixes in this area (which involve some small
> kernel patches sys/dev/usb/usb_generic.c), mostly if you start and stop
> transfers rapidly.

I never start/stop transfers.  Just submit one async bulk transfer
after the other.

Is there a limit how many transfers are allowed to be pending?  Or a
old bug that is triggered by bursts of small transfers?

> Also make sure that you don't mix synchronous and asynchronous transfers and
> that only synchronous transfer is executed at a time. I.E. no multithreading
> with synchronous transfers on the same USB device. Then you need to do it
> asynchronously if you need background reading.

No synchronous transfers at all.

No multithreading, I just have loop that polls stdin/stdout and the
usb fds.  Reading transfers from stdin and writing completed IN
transfers to stdout.

On the other end of stdin/stdout is a Erlang system that does all the
other protocol levels.

-- Peer

>
>
>
> --HPS
>
>
> -----Original message-----
> From: Hans Petter Selasky <hans.petter.selasky at bitfrost.no>
> Sent: Fri 19-10-2012 11:44
> Subject: Re: USB transfers stuck in kernel/libusb not sent out until next
> transfer is submitted
> To: peerst at gmail.com;
>
> Hi,
>
>
>
> You should check using usbdump if the USB transfer is actually submitted. If
> it is submitted, then it is most likely a problem with the USB device, that
> it is NAK'ing on the endpoint. Are you short terminating properly for FULL
> speed? Else it is a problem in libusb and/or the application.
>
>
>
> usbdump -i usbusX -f Y -vvv -s 65536
>
>
>
> --HPS