[RFC] [PATCH] usbatm.[ch]: multiple changes

[matthieu castet]

Hi Roman,

Roman Kagan wrote:
> On Fri, Apr 01, 2005 at 08:05:30PM +0200, matthieu castet wrote:
> 
>>Roman Kagan wrote:
>>
>>>Hmm, if you use 1007 bytes == 19 cells per iso frame (you don't use
>>>padding, do you?) and want 16 iso frames per urb you need buffer size of
>>>19 * 16 = 304.  503 shouldn't be a problem too, however, from the
>>>aesthetic POV I'd suggest a multiple of iso frame size, say 494 or 513.
>>
>>well I need to investigate, I set it to 304 and it work well :)
> 
> 
> Wow!  I'm really glad to hear that!  Still, playing with buffer size
> would be interesting...
Yes, using the default (64) make it worse : 8Ko/s and lot's of error.

I think I will try to do a script for doing a test automatically.
Have you got an idea of the range and the interval of the buffer size 
for the test ?


> 
> 
>>>Yep, that's the notorious -EILSEQ you were seeing before...
>>
>>There no need for the attached patch as -EILSEQ  seems to appear only 
>>when the modem failed to fill to urb (so only when the modem send 
>>nothing)...
> 
> 
> I'm a bit confused.  Have -EILSEQ errors disappeared now?  That is
> really surprizing: I don't see anything fundamentally different from USB
> POV in my new code as compared to the current CVS code, where you added
> that workaround to ignore -EILSEQ errors...
No there still -EILSEQ errors, but in your code there a timer, that
resubmit in case of error. But yes, your patch ignoring -EILSEQ is needed.

I also try on an intel chipset and there is the same error...



> 
> 
>>Also because you mix in your error count urb_submit and urb->status the 
>>counter is always 0 or 1...
> 
> 
> Right, I didn't realize that there might be a pattern of repetitive
> successes on submission and failures on completion.  What would be a
> better way to handle this?  Introduce separate counters for subission
> and completion?
Yes separate counters could be a solution.


cheers

matthieu