Handling -ETIMEDOUT for a Bulk In request

["Dale Martenson" <dmartenson@xxxxxxxxxxxxx>]

I have run into a case where read URBs stop being issued after receiving
an -ETIMEDOUT error. I am trying to get a USB modem which uses TI3410
chipset to work with an embedded server card running Linux 2.4.26. I
used an analyzer and saw that things seemed to be running fine after
enumeration, but that once the modem was opened and being used that
polling of the bulk in endpoint 1 stops. Once this happens data can
still be sent to the modem via bulk out to the endpoint 1, but no
response data is received. A -ETIMEDOUT error is received by the bulk in
callback routine. This stops the read URB and doesn't resubmit it. If I
change the driver to resubmit the URB, similar to handling done for the
-EPIPE status, communication across the USB interface is restored, but
it has a big negative side effect in that if you pull the modem with the
port open things "lock up".

How should -ETIMEDOUT be handled?

When I change the driver to resubmit the URB, the -ETIMEDOUT error
occurs every 2 seconds. The USB analyzer shows bulk in tokens being sent
every ~22 microseconds. Who raises the -ETIMEDOUT error? Why every 2
seconds? 

I have seen cases where the interval in the URB is too short and should
be lengthened, but I am not sure if this falls into that category. 

Any insight would be appreciated.

-Dale Martenson


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
linux-usb-devel@xxxxxxxxxxxxxxxxxxxxx
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel