U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Subject: [PATCH] usb: ehci: Fix "EHCI timed out on TD - token=XXXX" error on ehci-hcd
Date: Mon, 2 Mar 2020 14:54:28 -0500	[thread overview]
Message-ID: <20200302195428.GD18302@bill-the-cat> (raw)
In-Reply-To: <fd1a133f-30e8-9c88-39dd-49c20f18b0d7@denx.de>

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.

-- 
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/57de9ad2/attachment.sig>

  reply	other threads:[~2020-03-02 19:54 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 11:29 [PATCH] usb: ehci: Fix "EHCI timed out on TD - token=XXXX" error on ehci-hcd Lukasz Majewski
2020-02-26 16:05 ` Tom Rini
2020-02-28 23:32 ` Marek Vasut
2020-02-29  3:20   ` Tom Rini
2020-02-29  7:20     ` Marek Vasut
2020-03-01 23:04       ` Tom Rini
2020-03-02  0:39         ` Marek Vasut
2020-03-02 17:00           ` Tom Rini
2020-03-14 18:16             ` Marek Vasut
2020-03-01 17:19   ` Lukasz Majewski
2020-03-01 17:35     ` Marek Vasut
2020-03-01 17:59       ` Lukasz Majewski
2020-03-01 18:39         ` Marek Vasut
2020-03-02 13:01           ` Lukasz Majewski
2020-03-02 19:08             ` Marek Vasut
2020-03-02 13:21 ` Lukasz Majewski
2020-03-02 19:19   ` Marek Vasut
2020-03-02 19:54     ` Tom Rini [this message]
2020-03-02 19:58       ` Marek Vasut
2020-03-02 19:59         ` Tom Rini
2020-03-02 23:25     ` Lukasz Majewski
2020-03-03 12:29       ` Marek Vasut

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200302195428.GD18302@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox