Re: [Libusb-devel] Timeouts

[David G. <dav...@gm...>]

On Mon, Mar 12, 2012 at 1:49 PM, Alan Stern <st...@ro...>wrote:

> On Mon, 12 Mar 2012, David Grant wrote:
>
> > Is it a sign of buggy hardware/firmware in the
> > kernel/device?
>
> Sometimes yes, especially when devices have buggy firmware.
>
> > A bug in libusb?
>
> No, probably not.  Although it does help to use the most recent version
> of libusb (which has not yet been released officially).
>

Ok thanks.


>
> > What is the likelihood that they are caused
> > by something I am doing wrong in my code that calls libusb?
>
> Somewhere between 0% and 100%.  :-)  Seriously, how do you expect
> anyone on the mailing list to know the answer when you haven't provided
> any details at all?
>

Nope!


>
> It's like saying "If I try to drive to the train station and arrive too
> late, what's the likelihood that I got stuck in a traffic jam?"
>

Yeah I wasn't looking for an exact answer here. Just some things to rule
out. Actually libusb was one of the things that I really wanted to rule
out. I have been using trunk for a while.

I'll send more details when I have something, although given that libusb is
probably not the source of the problem, I won't post here unless I somehow
think libusb may be the culprit. We are developing for an ARM platform that
is really buggy. There are a couple of clear-cut examples where a device
will fail to work due to timeouts on this ARM platform, yet work
beautifully on a Linux x86 machine running the same software (and using the
devices with other Linux software is also problematic on the ARM platform).
Then there was another device yesterday (a HID interface for volme control
on USB speakers) that was experiencing timeouts on the Linux x86 machine.
However these seem to occur in conjuction with urb transfer errors on the
isochronous interface as well (ie. we get both errors, or none it seems).
Seems like it's device or hardware-related. Anyways, we have more testing
to do.

Thanks for your help!

Dave