RE: [tegrarcm PATCH v1 4/4] Increate USB timeout value

[Jimmy Zhang <jimmzhang-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>]

> -----Original Message-----
> From: Stephen Warren [mailto:swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org]
> Sent: Wednesday, March 09, 2016 9:41 AM
> To: Jimmy Zhang
> Cc: Allen Martin; Stephen Warren; alban.bedel-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org; linux-
> tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [tegrarcm PATCH v1 4/4] Increate USB timeout value
> 
> On 03/08/2016 06:41 PM, Jimmy Zhang wrote:
> >
> >
> >> -----Original Message-----
> >> From: Stephen Warren [mailto:swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org]
> >> Sent: Monday, March 07, 2016 11:40 AM
> >> To: Jimmy Zhang
> >> Cc: Allen Martin; Stephen Warren; alban.bedel-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org;
> >> linux- tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >> Subject: Re: [tegrarcm PATCH v1 4/4] Increate USB timeout value
> >>
> >> On 03/04/2016 04:44 PM, Jimmy Zhang wrote:
> >>> It has been observed that some times USB time out could occure when
> >>> a long (3ft) usb cable is connected to recovery mode usb port
> >>
> >> This explanation makes no sense. 3ft is practically the shortest USB
> >> cable anyone would use. Equally, assuming a compliant correctly
> >> functioning cable, cable length doesn't affect the time it takes to execute
> transactions.
> >>
> >> Is the issue more that if a low quality cable is used, then there are
> >> lots of transfer errors, and the time taken for retries is large? If
> >> so, there's not much guarantee that a larger timeout would help in
> >> general, since there's no guarantee of any upper bound on the time it
> >> takes for a packet not to get corrupted in this case. Still, I
> >> suppose it's fine to increase the timeout to account for when it
> accidentally works.
> >>
> >> In summary: a commit description that more accurately represents the
> >> problem being solved is required.
> >
> > We have seen this problem since T30/T114. Initially we just retried by
> downloading again. It may work after a few tries. Later, we found a simple
> solution is replacing with a shorter cable. Then one day, for testing purpose,
> when the timeout value was replaced with 0, ie, unlimited timeout, all cables
> work fine. So, it may worth to figure out the root cause.
> 
> There's obviously some variability here, since you mention that the
> communication works sometimes and not others.
> 
> When you tested the varying cable lengths, did you test at least 10x more
> times than the percentage of times that pass or fail with the original cable
> you used? Without testing a large number of times, you don't know if you
> just got lucky the one time you tried a different cable, or whether it really
> made a statistical difference.
> 
> Much more likely is that Tegra itself sometimes takes more time to respond,
> or sometimes receives/sends packets that get corrupted somewhere and
> have to be retried.
> 
> BTW, have you tried using Wireshark and usbmon to capture a trace of the
> failures to try and diagnose the issue?
> 
> Finally, I'm not objecting to this patch if it does work around the problem. All
> I'm objecting to is blaming the issue on cable length when I'm not convinced
> that's been conclusively proven. A simple message such as the following
> would work:
> 
Agree. We actually never pay much attention to the tool issue because the focus is always on the task performed at that moment.

As Allen suggested, I will create a new usb_timeout command line parameter to allow user to set timeout value.
  
> RCM communication sometimes fails if the USB timeout is short. Increase the
> timeout value to avoid this issue. The exact cause is not yet diagnosed.