[PATCH] usb: ehci: Fix "EHCI timed out on TD - token=XXXX" error on ehci-hcd

[Tom Rini]

On Mon, Mar 02, 2020 at 08:58:26PM +0100, Marek Vasut wrote:
> On 3/2/20 8:54 PM, Tom Rini wrote:
> > On Mon, Mar 02, 2020 at 08:19:22PM +0100, Marek Vasut wrote:
> >> On 3/2/20 2:21 PM, Lukasz Majewski wrote:
> >>> Hi,
> >>
> >> Hi,
> >>
> >>>> This patch aims to improve robustness of 'usb' command operation on
> >>>> the ehci-hcd IP block as it ports to contemporary U-Boot the patch
> >>>> described and provided in [1] (originally applicable to U-Boot
> >>>> 2016.05).
> >>>>
> >>>> According to the fix author - "rayvt" (from [1]):
> >>>>
> >>>> TD stands for "Queue Element Transfer Descriptor (qTD)", which is a
> >>>> micro-code instruction for the EHCI USB chip.
> >>>> The "token" field is detailed information, control, and status of the
> >>>> TD's data transfer. In particular, the rightmost byte is the status
> >>>> field. 0x80 bit means the TD is active and the data transfer has not
> >>>> yet completed. 0x08 bit means there was some sort of data transfer
> >>>> error (XactErr).
> >>> 	 ^^^^^^^ - this error is NOT handled now in mainline u-boot. Do
> >>> 	 you have any experience with it?
> >>
> >> No, but then I also didn't run into those yet.
> >>
> >>>> If the drive gets a transfer error, it refuses to do any other I/O
> >>>> transfer until the error is properly cleared and reset. U-boot did
> >>>> not do this, so every subsequent disk read would get a timeout error
> >>>> because the drive would not send any data. The fix is to properly
> >>>> clear and reset the USB disk when it gets a transfer error.
> >>
> >> So basically, what this says is, "we crashed the drive, because the
> >> drive suffered counter overflow, thus we fix it by resetting the drive".
> >> No, the fix is to not crash the drive in the first place.
> >>
> >>>> Every read operation starts at the maximum block size. When the USB
> >>>> pendrive is not able to correctly serve this data read request, the
> >>>> dynamic reduction of IO size is performed. Up to six tries (with
> >>>> smaller IO block each time) are attempted.
> >>>>
> >>>> A related problem is that some drives are slow to come up. Linux
> >>>> handles this by issuing a spinup command and allowing more time for
> >>>> the drive to respond. The same idea is applied in this fix.
> >>>>
> >>>> On TPC70 (i.MX6Q) once per ~10 times (without this patch):
> >>>>
> >>>> Bus usb at 2184200: USB EHCI 1.00
> >>>> scanning bus usb at 2184200 for devices... 2 USB Device(s) found
> >>>>        scanning usb for storage devices... 1 Storage Device(s) found
> >>>> EHCI timed out on TD - token=0x1f8c80
> >>>
> >>> This is how the error gets evident. The detailed explanation is in link
> >>> [1].
> >>
> >> Is there one specific post in that forum, or do I need to read through
> >> the whole multi-page thread ?
> >>
> >> I would expect that if you run -- I assume 'usb reset' (the command is
> >> missing above) -- then the bus gets power-cycled, hence the USB device
> >> also gets power-cycled.
> > 
> > FWIW, the problem I have does not get fixed via "usb reset".  Ethernet
> > never shows up again.  I do see right now that I disabled network tests
> > on the platform a long while ago for unknown reasons, but did comment to
> > myself elsewhere that network was fairly flaky in U-Boot.
> 
> There certainly is something with USB ethernet in U-Boot. I noticed the
> flakiness myself, but didn't have time to investigate. Patches welcome I
> guess ?

Looking forward to testing them!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200302/641aed36/attachment.sig>