All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] USB2.0 device timeout issue.
@ 2017-05-10  7:09 Terry Zhou
  2017-05-15  3:02 ` Simon Glass
  0 siblings, 1 reply; 6+ messages in thread
From: Terry Zhou @ 2017-05-10  7:09 UTC (permalink / raw)
  To: u-boot

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 at 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?
Thanks.

Best Regards,
Terry

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] USB2.0 device timeout issue.
  2017-05-10  7:09 [U-Boot] USB2.0 device timeout issue Terry Zhou
@ 2017-05-15  3:02 ` Simon Glass
  2017-05-15  3:51   ` [U-Boot] [EXT] " Wilson Ding
  0 siblings, 1 reply; 6+ messages in thread
From: Simon Glass @ 2017-05-15  3:02 UTC (permalink / raw)
  To: u-boot

+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 at 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [EXT] Re: USB2.0 device timeout issue.
  2017-05-15  3:02 ` Simon Glass
@ 2017-05-15  3:51   ` Wilson Ding
  2017-05-17  7:01     ` Terry Zhou
  0 siblings, 1 reply; 6+ messages in thread
From: Wilson Ding @ 2017-05-15  3:51 UTC (permalink / raw)
  To: u-boot

+ Nadav

-----Original Message-----
From: sjg@google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
Sent: 2017年5月15日 11:03
To: Terry Zhou <bjzhou@marvell.com>
Cc: u-boot at 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 at 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [EXT] Re: USB2.0 device timeout issue.
  2017-05-15  3:51   ` [U-Boot] [EXT] " Wilson Ding
@ 2017-05-17  7:01     ` Terry Zhou
  2017-05-17  7:23       ` Marek Vasut
  0 siblings, 1 reply; 6+ messages in thread
From: Terry Zhou @ 2017-05-17  7:01 UTC (permalink / raw)
  To: u-boot

HI Marek,
Do you have any comments/suggestions on this issue?
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 at 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 at google.com] On Behalf Of Simon Glass
Sent: 2017年5月15日 11:03
To: Terry Zhou <bjzhou@marvell.com>
Cc: u-boot at 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 at 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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] [EXT] Re: USB2.0 device timeout issue.
  2017-05-17  7:01     ` Terry Zhou
@ 2017-05-17  7:23       ` Marek Vasut
  0 siblings, 0 replies; 6+ messages in thread
From: Marek Vasut @ 2017-05-17  7:23 UTC (permalink / raw)
  To: u-boot

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 at 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 at google.com [mailto:sjg at google.com] On Behalf Of Simon Glass
> Sent: 2017年5月15日 11:03
> To: Terry Zhou <bjzhou@marvell.com>
> Cc: u-boot at 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 at 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.

-- 
Best regards,
Marek Vasut

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [U-Boot] USB2.0 device timeout issue.
@ 2017-05-10  6:55 Terry Zhou
  0 siblings, 0 replies; 6+ messages in thread
From: Terry Zhou @ 2017-05-10  6:55 UTC (permalink / raw)
  To: u-boot

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 at 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?
Thanks.

Best Regards,
Terry

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2017-05-17  7:23 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-10  7:09 [U-Boot] USB2.0 device timeout issue Terry Zhou
2017-05-15  3:02 ` Simon Glass
2017-05-15  3:51   ` [U-Boot] [EXT] " Wilson Ding
2017-05-17  7:01     ` Terry Zhou
2017-05-17  7:23       ` Marek Vasut
  -- strict thread matches above, loose matches on Subject: below --
2017-05-10  6:55 [U-Boot] " Terry Zhou

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.