On 07/21/2016 10:08 AM, Rajesh Bhagat wrote: > Hello Marek, > > Any comments?
If I recall correctly, this broke things for Matthew. Is this resolved ? >> -----Original Message----- >> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Rajesh Bhagat >> Sent: Tuesday, June 28, 2016 12:14 PM >> To: Matthew Bright <matthew.bri...@alliedtelesis.co.nz>; Marek Vasut >> <ma...@denx.de> >> Cc: u-boot@lists.denx.de; Chris Packham <chris.pack...@alliedtelesis.co.nz>; >> Mark >> Tomlinson <mark.tomlin...@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.bri...@alliedtelesis.co.nz] >>> Sent: Thursday, June 23, 2016 8:23 AM >>> To: Marek Vasut <ma...@denx.de>; Rajesh Bhagat <rajesh.bha...@nxp.com> >>> Cc: u-boot@lists.denx.de; Chris Packham >>> <chris.pack...@alliedtelesis.co.nz>; Mark Tomlinson >>> <mark.tomlin...@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.bri...@alliedtelesis.co.nz] >>>>> Sent: Wednesday, June 22, 2016 11:42 AM >>>>> To: Rajesh Bhagat <rajesh.bha...@nxp.com>; ma...@denx.de >>>>> Cc: u-boot@lists.denx.de; Chris Packham >>>>> <chris.pack...@alliedtelesis.co.nz>; Mark Tomlinson >>>>> <mark.tomlin...@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 (han...@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@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot > > Best Regards, > Rajesh Bhagat > -- Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
