[U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks
Rajesh Bhagat
rajesh.bhagat at nxp.com
Thu Jul 21 10:08:08 CEST 2016
Hello Marek,
Any comments?
> -----Original Message-----
> From: U-Boot [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Rajesh Bhagat
> Sent: Tuesday, June 28, 2016 12:14 PM
> To: Matthew Bright <Matthew.Bright at alliedtelesis.co.nz>; Marek Vasut
> <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: Re: [U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement
> logic to calculate optimal usb maximum trasfer blocks
>
>
>
> > -----Original Message-----
> > From: Matthew Bright [mailto:Matthew.Bright at alliedtelesis.co.nz]
> > Sent: Thursday, June 23, 2016 8:23 AM
> > To: Marek Vasut <marex at denx.de>; Rajesh Bhagat <rajesh.bhagat at nxp.com>
> > Cc: u-boot at lists.denx.de; Chris Packham
> > <Chris.Packham at alliedtelesis.co.nz>; Mark Tomlinson
> > <Mark.Tomlinson at alliedtelesis.co.nz>
> > Subject: Re: testing: [PATCH v7 0/3] common: usb_storage: Implement
> > logic to calculate optimal usb maximum trasfer blocks
> >
> > 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
> >
>
> Hello Matt/Marek,
>
> I'm working on enabling CONFIG_DM_USB for EHCI and XHCI controllers and found
> one more issue which this patch is solving.
>
> When both EHCI and XHCI are defined using CONFIG_DM_USB, the value of
> USB_MAX_XFER_BLK becomes 65535 according to current implementation.
> And is causing read/write issues in XHCI, though EHCI is working fine.
> (Please check below logs).
>
> Hence, extending this patch from EHCI to XHCI is very much required as pointed out
> by Matt. When I apply this patch after extending it for XHCI also, below problem is
> solved (check observations below).
>
>
> Observations:
> 1. "usb start" correctly detected two devices one in high speed and one in super speed
> on EHCI and XHCI controller respectively .
>
> => usb start
> starting USB...
> USB0: USB EHCI 1.00
> USB1: Register 200017f NbrPorts 2
> Starting the controller
> USB XHCI 1.00
> scanning bus 0 for devices... 2 USB Device(s) found scanning bus 1 for devices... 2
> USB Device(s) found
>
> 2. Read/write on high speed device on EHCI port worked fine.
>
> => usb dev 0
>
> USB device 0:
> Device 0: Vendor: SanDisk Rev: 1.26 Prod: Cruzer Blade
> Type: Hard Disk
> Capacity: 7633.5 MB = 7.4 GB (15633408 x 512) ... is now current device =>
> mw 81000000 55555555 800000; mw a0000000 aaaaaaaa 800000; usb write
> a0000000 0 10000; usb read 81000000 0 10000; cmp.b a0000000 81000000 2000000;
>
> USB write: device 0 block # 0, count 65536 ... 65536 blocks write: OK
>
> USB read: device 0 block # 0, count 65536 ... 65536 blocks read: OK Total of
> 33554432 byte(s) were the same
>
> 3. Read/write on super speed device on XHCI port, I'm getting below error
>
> => usb dev 1
> USB device 1:
> Device 1: Vendor: JetFlash Rev: 1100 Prod: Transcend 16GB
> Type: Removable Hard Disk
> Capacity: 15360.0 MB = 15.0 GB (31457280 x 512) ... is now current device
> => mw 81000000 55555555 800000; mw a0000000 aaaaaaaa 800000; usb write
> a0000000 0 10000; usb read 81000000 0 10000; cmp.b a0000000 81000000 2000000;
>
> USB write: device 1 block # 0, count 65536 ... WARN halted endpoint, queueing URB
> anyway.
> Unexpected XHCI event TRB, skipping... (fef27250 00000000 13000000 01008401)
> BUG: failure at drivers/usb/host/xhci-ring.c:489/abort_td()!
> BUG!
>
>
> Best Regards,
> Rajesh Bhagat
>
> > Cheers.
> > - Matt Bright
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
Best Regards,
Rajesh Bhagat
More information about the U-Boot
mailing list