+ Nadav

-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: 2017年5月15日 11:03 To: Terry Zhou bjzhou@marvell.com Cc: u-boot@lists.denx.de; Wilson Ding dingwei@marvell.com; Stefan Roese sr@denx.de; Marek Vasut marex@denx.de Subject: [EXT] Re: USB2.0 device timeout issue.

External Email

---------------------------------------------------------------------- +Marek

Hi Terry,

On 10 May 2017 at 01:09, Terry Zhou bjzhou@marvell.com wrote:

Hi all,

This is Terry from Marvell BSP team in ShangHai China.

We got one issue in USB like below:

1.  When reading large files(larger than 32M ) from USB2.0 u-disk, two
   

of the disks got the timeout error like below:

Marvell>> fatload usb 0:1 0x1000000 got.mkv 0x2000000 reading got.mkv EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 Error reading cluster ** Unable to read file got.mkv **

2.  I did some research on this issue and found that this issue
   

disappear if we set “USB_MAX_XFER_BLK” to a smaller value.

/common/usb_storage.c

@@ -145,7 +145,7 @@ struct us_data {

• limited to 65535 blocks.

*/

#elif defined(CONFIG_USB_EHCI)

-#define USB_MAX_XFER_BLK 65535

+#define USB_MAX_XFER_BLK 8000

3.  We also did some test in linux, it works in linux, we found that
   

linux set the max_sectors to 240, and even we set them to a larger value,

The maximum value is 512, which is safe compares to the 8000 in Uboot.

Reference link for linux: http://www.linux-usb.org/FAQ.html#i5

4.  I found in Uboot forum, other guys met the same problem with us, see
   

the link below:

https://lists.denx.de/pipermail/u-boot/2016-February/246405.html

and there is also some patches to find the optimal value of USB_MAX_XFER_BLK

https://www.mail-archive.com/u-boot@lists.denx.de/msg215952.html

But these patches have not been pushed to the mainline code.

Could you please share your ideas, why we didn’t merge the patches and how should we fix this issue?

I'm not sure why they were not merged. It looks like there were some comments to address? If that is true then you could resend the series yourself with the fixes and get it applied.

Regards, Simon

On 05/17/2017 09:01 AM, Terry Zhou wrote:

HI Marek,

Hi,

Do you have any comments/suggestions on this issue?

Please stop top-posting, the thread is complete chaos now.

Thanks

Best Regards, Terry

-----Original Message----- From: Wilson Ding Sent: 2017年5月15日 11:52 To: Simon Glass sjg@chromium.org; Terry Zhou bjzhou@marvell.com Cc: u-boot@lists.denx.de; Stefan Roese sr@denx.de; Marek Vasut marex@denx.de; Nadav Haklai nadavh@marvell.com Subject: RE: [EXT] Re: USB2.0 device timeout issue.

• Nadav

-----Original Message----- From: sjg@google.com [mailto:sjg@google.com] On Behalf Of Simon Glass Sent: 2017年5月15日 11:03 To: Terry Zhou bjzhou@marvell.com Cc: u-boot@lists.denx.de; Wilson Ding dingwei@marvell.com; Stefan Roese sr@denx.de; Marek Vasut marex@denx.de Subject: [EXT] Re: USB2.0 device timeout issue.

External Email

---

+Marek

Hi Terry,

On 10 May 2017 at 01:09, Terry Zhou bjzhou@marvell.com wrote:

...

Hi all,

This is Terry from Marvell BSP team in ShangHai China.

We got one issue in USB like below:

1.  When reading large files(larger than 32M ) from USB2.0 u-disk, two
   

of the disks got the timeout error like below:

Marvell>> fatload usb 0:1 0x1000000 got.mkv 0x2000000 reading got.mkv EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 EHCI timed out on TD - token=0x1e008d80 Error reading cluster ** Unable to read file got.mkv **

2.  I did some research on this issue and found that this issue
   

disappear if we set “USB_MAX_XFER_BLK” to a smaller value.

/common/usb_storage.c

@@ -145,7 +145,7 @@ struct us_data {

• limited to 65535 blocks.

*/

#elif defined(CONFIG_USB_EHCI)

-#define USB_MAX_XFER_BLK 65535

+#define USB_MAX_XFER_BLK 8000

3.  We also did some test in linux, it works in linux, we found that
   

linux set the max_sectors to 240, and even we set them to a larger value,

The maximum value is 512, which is safe compares to the 8000 in Uboot.

Reference link for linux: http://www.linux-usb.org/FAQ.html#i5

4.  I found in Uboot forum, other guys met the same problem with us, see
   

the link below:

https://lists.denx.de/pipermail/u-boot/2016-February/246405.html

and there is also some patches to find the optimal value of USB_MAX_XFER_BLK

https://www.mail-archive.com/u-boot@lists.denx.de/msg215952.html

But these patches have not been pushed to the mainline code.

Could you please share your ideas, why we didn’t merge the patches and how should we fix this issue?

I'm not sure why they were not merged. It looks like there were some comments to address? If that is true then you could resend the series yourself with the fixes and get it applied.

Agreed, fix the comments and repost, although I suspect we can't really fix the problem with shitty sticks without some sort of blacklist or so.