[U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks

[Matthew Bright]

On 06/23/2016 01:02 AM, Marek Vasut wrote:
>
>On 06/22/2016 08:36 AM, Rajesh Bhagat wrote:
>> 
>> From: Matthew Bright [mailto:Matthew.Bright at alliedtelesis.co.nz] 
>> Sent: Wednesday, June 22, 2016 11:42 AM
>> To: Rajesh Bhagat <rajesh.bhagat at nxp.com>; marex at denx.de
>> Cc: u-boot at lists.denx.de; Chris Packham <Chris.Packham at alliedtelesis.co.nz>; Mark Tomlinson <Mark.Tomlinson at alliedtelesis.co.nz>
>> Subject: testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks
>> 
>> On 06/16/2016 12:35 PM, Rajesh Bhagat wrote:
>>> Performs code cleanup by making common function for usb_stor_read/write
>>> and implements the logic to calculate the optimal usb maximum trasfer blocks
>>> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case
>>> of EHCI and other USB protocols respectively.
>>>  
>>> Rajesh Bhagat (3):
>>>   common: usb_storage: Make common function for usb_read_10/usb_write_10
>>>   common: usb_storage: Make common function for
>>>     usb_stor_read/usb_stor_write
>>>   common: usb_storage : Implement logic to calculate optimal usb maximum
>>>     trasfer blocks
>>>  
>>>  common/usb_storage.c | 213 +++++++++++++++++++++++----------------------------
>>>  include/usb.h        |   1 +
>>>  2 files changed, 98 insertions(+), 116 deletions(-)
>>>  
>>>
>>> Hi Rajesh & Marek
>>>
>>> I have spend the last couple of days testing these patches on the
>>> v2016.05 release, with an usb mass storage device that is able to
>>> consistently reproduce the USB_MAX_XFER_BLK issue as described in
>>> the "Issue with USB mass storage (thumb drives)" u-boot thread.
>>>
>>> http://lists.denx.de/pipermail/u-boot/2016-February/244464.html​
>>>
>> 
>> Hello Matt, 
>> 
>>> I can confirm the patch correctly increases the max transfer bocks
>>> after a successful read, and decreases the max transfer bocks after
>>> a read failure. However, I have noticed that once the ehci time out
>>> error occurs, the usb device appears to lock up. When in this state
>>> the usb device will stop responding to any further transfers. This
>>> behavior is independent of the number of blocks, and will continue
>>> until the ehci has been reset.
>>>
>> 
>> I believe the lockup behavior mentioned by you to be device specific quirk. 
>> I tested 3 pen drives, which recovered from EHCI timeout behavior by 
>> reducing the number of blocks (check below output): 
>> 
>
>3 devices is not a representative sample.
>
>-- 
>Best regards,
>Marek Vasut

I agree.

Several others on the u-boot threads have also reported the same ehci
time out issue related to the max transfer blocks. Perhaps we could
kindly ask if they could also test the patch ...

Schrempf Frieder
http://lists.denx.de/pipermail/u-boot/2016-February/244464.html
http://lists.denx.de/pipermail/u-boot/2016-February/245893.html

Hannes Schmelzer (hannes at schmelzer.or.at)
http://lists.denx.de/pipermail/u-boot/2016-February/244621.html

Maxime Jayat
http://lists.denx.de/pipermail/u-boot/2016-February/246267.html

Diego
http://lists.denx.de/pipermail/u-boot/2016-April/251799.html

Nicolas Chauvet
http://lists.denx.de/pipermail/u-boot/2016-May/256117.html

As a side note, there appears to be a subtle a difference in the
output when the usb device locks up:

CASE 1: EHCI Time Out - Device Remains Responsive:

=> fatload usb 0 0x18000000 test.file
EHCI timed out on TD - token=0x2c008d80
EHCI timed out on TD - token=0xac008d80
EHCI timed out on TD - token=0xac008d80
Error reading cluster
** Unable to read file test.file **
=>

The three time out errors are caused by three attempts to send the
over-sized transfer before giving up.

CASE 2: EHCI Time Out - Device Locks Up:

=> fatload usb 0:auto 0x1000000 test.rel
reading test.rel
EHCI timed out on TD - token=0x26008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x801f8c80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
EHCI timed out on TD - token=0x80008d80
Error reading cluster
** Unable to read file test.rel **
=>

The additional time out errors are caused because the usb device also
fails to respond to several reset messages after the initial time out;
therefore providing a clear indication that the device has locked up.

The usb device in the initial thread appears to exhibit such behavior:
http://lists.denx.de/pipermail/u-boot/2016-February/244464.html

Cheers.
- Matt Bright