[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Anatolij Gustschin]

Checking the status field of the qTD token in the current code
do not take into acount cases where endpoint stall (halted) bit
is set together with some other status bits. As a result clearing
stall on an endpoint won't be done if other status bits were set.

E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
issue showed that while bulk IN transfers with length of 13 or
18 the status field of the qTD token sometimes indicates trans-
action error (XactErr) and sometimes additionally endpoint halted
state. In the latter case resetting the USB device in error
recovery code fails as no clear stall request on the endpoint
will be done. The patch fixes status field checking code to
properly handle endpoint halted state.

However this fix is not enough to solve 'usb start' problem
with hub/stick combination mentioned above. Running with lot of
debug code in ehci_submit_async() I've never seen the problem
with usb stick recognition. After removing this debug code the
similar problem sometimes showed up again. Therefore the patch
also adds delay in ehci_submit_async() for above-mentioned
hub/stick combination. Even without this delay the fix is an
improvement since it fixes the problem with board freezy after
subsequent failed 'usb start/stop' cycles as it was observed
on mpc5121ads board.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
 common/usb_storage.c        |    5 +++--
 drivers/usb/host/ehci-hcd.c |    8 ++++++++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/common/usb_storage.c b/common/usb_storage.c
index 76949b8..5ca92c3 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -680,7 +680,8 @@ int usb_stor_BBB_transport(ccb *srb, struct us_data *us)
 	result = usb_bulk_msg(us->pusb_dev, pipe, srb->pdata, srb->datalen,
 			      &data_actlen, USB_CNTL_TIMEOUT * 5);
 	/* special handling of STALL in DATA phase */
-	if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
+	if ((result < 0) &&
+	    (us->pusb_dev->status & (USB_ST_STALLED | USB_ST_CRC_ERR))) {
 		USB_STOR_PRINTF("DATA:stall\n");
 		/* clear the STALL on the endpoint */
 		result = usb_stor_BBB_clear_endpt_stall(us,
@@ -710,7 +711,7 @@ again:
 
 	/* special handling of STALL in STATUS phase */
 	if ((result < 0) && (retry < 1) &&
-	    (us->pusb_dev->status & USB_ST_STALLED)) {
+	    (us->pusb_dev->status & (USB_ST_STALLED | USB_ST_CRC_ERR))) {
 		USB_STOR_PRINTF("STATUS:stall\n");
 		/* clear the STALL on the endpoint */
 		result = usb_stor_BBB_clear_endpt_stall(us, us->ep_in);
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 37d056e..7463a75 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -430,6 +430,12 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer,
 	usbsts = ehci_readl(&hcor->or_usbsts);
 	ehci_writel(&hcor->or_usbsts, (usbsts & 0x3f));
 
+	if (dev->descriptor.idVendor == 0x930 &&
+	    dev->descriptor.idProduct == 0x6545 &&
+	    dev->parent->descriptor.idVendor == 0x424 &&
+	    dev->parent->descriptor.idProduct == 0x2514)
+		wait_ms(10);
+
 	/* Enable async. schedule. */
 	cmd = ehci_readl(&hcor->or_usbcmd);
 	cmd |= CMD_ASE;
@@ -490,6 +496,8 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer,
 			break;
 		default:
 			dev->status = USB_ST_CRC_ERR;
+			if ((token & 0x40) == 0x40)
+				dev->status |= USB_ST_STALLED;
 			break;
 		}
 		dev->act_len = length - ((token >> 16) & 0x7fff);
-- 
1.7.0.4

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Remy Bohmer]

Hi,

2010/8/31 Anatolij Gustschin <agust@denx.de>:
> Checking the status field of the qTD token in the current code
> do not take into acount cases where endpoint stall (halted) bit
> is set together with some other status bits. As a result clearing
> stall on an endpoint won't be done if other status bits were set.

Reading this description and this code:

>        /* special handling of STALL in DATA phase */
> -       if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
> +       if ((result < 0) &&
> +           (us->pusb_dev->status & (USB_ST_STALLED | USB_ST_CRC_ERR))) {
>                USB_STOR_PRINTF("DATA:stall\n");

Description and code do not seem to match. The old implementation
explicitly checked if the STALLED bit was set, and if so the endpoint
would be cleared. Now, it seems you are clearing the endpoint _also_
when the CRC_ERR bit is set.

There are a lot more reasons, at least on other host controllers that
set the status USB_ST_CRC_ERR, does this change not break the other
code? (A simple grep will show you the situations where it is
returned.)

> E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
> connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
> issue showed that while bulk IN transfers with length of 13 or
> 18 the status field of the qTD token sometimes indicates trans-
> action error (XactErr) and sometimes additionally endpoint halted
> state. In the latter case resetting the USB device in error
> recovery code fails as no clear stall request on the endpoint
> will be done.

OK

> However this fix is not enough to solve 'usb start' problem
> with hub/stick combination mentioned above. Running with lot of
> debug code in ehci_submit_async() I've never seen the problem
> with usb stick recognition. After removing this debug code the
> similar problem sometimes showed up again. Therefore the patch
> also adds delay in ehci_submit_async() for above-mentioned
> hub/stick combination. Even without this delay the fix is an

Why only for these USB sticks? Are these sticks special among the
thousands of different sticks out there?
Or could it be more reliable to always do this delay for all USB
sticks? Or even better, what are we missing here that the delay is
needed at all?

> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> index 37d056e..7463a75 100644
> --- a/drivers/usb/host/ehci-hcd.c
> +++ b/drivers/usb/host/ehci-hcd.c

Is this problem only valid for the EHCI code? I can imagine that the
other host controllers (like UHCI and OHCI and so on) code suffer the
same problem and need similar fixes...
(At least I know that I have here a couple of USB sticks that show
similar problems with OHCI ;-) )

Kind regards,

Remy

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Roland Kletzing]

Hello,

i`m searching for a solution for a while, so i`m trying my luck here. I`m 
using Seagate Dockstar (ARM926EJ-S based) NAS device and installed Debian 
ARM on that as documented at http://jeff.doozan.com/debian/

While it`s running fine with a sandisk flash usb stick and a sd-card in a 
usb cardreader, i`m not able to get the thingie boot with 2 different real 
2.5" ide disks attached to two different kinds of ide2usb converter cables.

The pogoplug linux (which runs on dockstar by default) detects the disks 
very fine and debian installation from there runs fine too, but booting from 
that always fails like this:

U-Boot 2010.06-00695-gbd23130-dirty (Aug 30 2010 - 23:04:56)
Marvell-Dockstar/Pogoplug by Jeff Doozan
Hit any key to stop autoboot:  0
(Re)start USB...
USB:   Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 3 USB Device(s) found
       scanning bus for storage devices... 1 Storage Device(s) found
** Bad partition 1 **
** Bad partition 1 **
Wrong Image Format for bootm command
ERROR: can't get kernel image!
stopping USB..


I found a LOT of references on the net where people report similar problems 
for sheevaplug, pogoplug, dockstar -  even with flash based media and just 
came across this posting on u-boot list. looks related to me!?

i assume there is something which needs be fixed in u-boot and this is not 
storage-device specific but must be specific to the usb chipset or platform.

the problem is that i don`t know how to unbrick dockstar yet, but i`d like 
to let you know that a lot of people will be happy if this gets fixed. i 
will read deeper into how to build uboot and safely replace it on my device, 
if there is anything more i can do to provide input or do testing please let 
me know. i think i can dig out tons of reports of similar issues. as my "i 
replace my homeserver with a dockstar"-projects depends on this, maybe i can 
even donate a dockstar for the person willing or be able to fix this issue.

from another post:
>Is this problem only valid for the EHCI code? I can imagine that the
>other host controllers (like UHCI and OHCI and so on) code suffer the
>same problem and need similar fixes...
>(At least I know that I have here a couple of USB sticks that show
>similar problems with OHCI ;-) )

If this helps - this is some info from a successful linux boot on that 
dockstar platform. usb runs perfectly when in linux, but it seems that there 
are problems only in u-boot.

[    1.180000] ehci_marvell ehci_marvell.70059: Marvell Orion EHCI
[    1.190000] ehci_marvell ehci_marvell.70059: new USB bus registered, 
assigned bus number 1
[    1.230000] ehci_marvell ehci_marvell.70059: irq 19, io base 0xf1050100
[    1.250000] ehci_marvell ehci_marvell.70059: USB 2.0 started, EHCI 1.00, 
driver 10 Dec 2004
[    1.250000] usb usb1: configuration #1 chosen from 1 choice
[    1.260000] hub 1-0:1.0: USB hub found
[    1.260000] hub 1-0:1.0: 1 port detected
[    1.380000] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller 
(OHCI) Driver
[    1.380000] USB Universal Host Controller Interface driver v3.0
[    1.660000] usb 1-1: new high speed USB device using ehci_marvell and 
address 2
[    1.810000] usb 1-1: configuration #1 chosen from 1 choice
[    1.810000] hub 1-1:1.0: USB hub found
[    1.820000] hub 1-1:1.0: 4 ports detected
[    2.170000] usb 1-1.3: new high speed USB device using ehci_marvell and 
address 3
[    2.270000] usb 1-1.3: configuration #1 chosen from 1 choice


regards
roland

ps:
 i found the following line in common/usb_storage.c - so maybe we cannot 
expect the usb code to work with real disks at all !?
/*
 * New Note:
 * Support for USB Mass Storage Devices (BBB) has been added. It has
 * only been tested with USB memory sticks.
 */




quote:
[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba 
USB stick
Anatolij Gustschin agust at denx.de
Tue Aug 31 20:45:14 CEST 2010
Previous message: [U-Boot] [PATCH] zlib: Add further watchdog reset calls
Next message: [U-Boot] [PATCH] [v2] mpc8610: refactor DIU initialization 
code to use existing bitmap and logo features
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Checking the status field of the qTD token in the current code
do not take into acount cases where endpoint stall (halted) bit
is set together with some other status bits. As a result clearing
stall on an endpoint won't be done if other status bits were set.

E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
issue showed that while bulk IN transfers with length of 13 or
18 the status field of the qTD token sometimes indicates trans-
action error (XactErr) and sometimes additionally endpoint halted
state. In the latter case resetting the USB device in error
recovery code fails as no clear stall request on the endpoint
will be done. The patch fixes status field checking code to
properly handle endpoint halted state.

However this fix is not enough to solve 'usb start' problem
with hub/stick combination mentioned above. Running with lot of
debug code in ehci_submit_async() I've never seen the problem
with usb stick recognition. After removing this debug code the
similar problem sometimes showed up again. Therefore the patch
also adds delay in ehci_submit_async() for above-mentioned
hub/stick combination. Even without this delay the fix is an
improvement since it fixes the problem with board freezy after
subsequent failed 'usb start/stop' cycles as it was observed
on mpc5121ads board.

Signed-off-by: Anatolij Gustschin <agust@denx.de>
---
 common/usb_storage.c        |    5 +++--
 drivers/usb/host/ehci-hcd.c |    8 ++++++++
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/common/usb_storage.c b/common/usb_storage.c
index 76949b8..5ca92c3 100644
--- a/common/usb_storage.c
+++ b/common/usb_storage.c
@@ -680,7 +680,8 @@ int usb_stor_BBB_transport(ccb *srb, struct us_data *us)
 	result = usb_bulk_msg(us->pusb_dev, pipe, srb->pdata, srb->datalen,
 			      &data_actlen, USB_CNTL_TIMEOUT * 5);
 	/* special handling of STALL in DATA phase */
-	if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
+	if ((result < 0) &&
+	    (us->pusb_dev->status & (USB_ST_STALLED | USB_ST_CRC_ERR))) {
 		USB_STOR_PRINTF("DATA:stall\n");
 		/* clear the STALL on the endpoint */
 		result = usb_stor_BBB_clear_endpt_stall(us,
@@ -710,7 +711,7 @@ again:

 	/* special handling of STALL in STATUS phase */
 	if ((result < 0) && (retry < 1) &&
-	    (us->pusb_dev->status & USB_ST_STALLED)) {
+	    (us->pusb_dev->status & (USB_ST_STALLED | USB_ST_CRC_ERR))) {
 		USB_STOR_PRINTF("STATUS:stall\n");
 		/* clear the STALL on the endpoint */
 		result = usb_stor_BBB_clear_endpt_stall(us, us->ep_in);
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 37d056e..7463a75 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -430,6 +430,12 @@ ehci_submit_async(struct usb_device *dev, unsigned long 
pipe, void *buffer,
 	usbsts = ehci_readl(&hcor->or_usbsts);
 	ehci_writel(&hcor->or_usbsts, (usbsts & 0x3f));

+	if (dev->descriptor.idVendor == 0x930 &&
+	    dev->descriptor.idProduct == 0x6545 &&
+	    dev->parent->descriptor.idVendor == 0x424 &&
+	    dev->parent->descriptor.idProduct == 0x2514)
+		wait_ms(10);
+
 	/* Enable async. schedule. */
 	cmd = ehci_readl(&hcor->or_usbcmd);
 	cmd |= CMD_ASE;
@@ -490,6 +496,8 @@ ehci_submit_async(struct usb_device *dev, unsigned long 
pipe, void *buffer,
 			break;
 		default:
 			dev->status = USB_ST_CRC_ERR;
+			if ((token & 0x40) == 0x40)
+				dev->status |= USB_ST_STALLED;
 			break;
 		}
 		dev->act_len = length - ((token >> 16) & 0x7fff);
-- 
1.7.0.4 

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Wolfgang Denk]

Dear "Roland Kletzing",

In message <9714EDEC3798462FACB91473A96284B8@samsungnetbook> you wrote:
> 
> i`m searching for a solution for a while, so i`m trying my luck here. I`m 
> using Seagate Dockstar (ARM926EJ-S based) NAS device and installed Debian 
> ARM on that as documented at http://jeff.doozan.com/debian/

You hijack a (pretty much unrelated) mail thread.

You top-post.

You full-quote.

And it seems you did not read neither
http://www.netmeister.org/news/learn2quote.html  nor
http://www.catb.org/~esr/faqs/smart-questions.html



I think your problem is completely unrelated to the Subject: you refer
to.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I can't understand it. I can't even understand  the  people  who  can
understand it.                    - Queen Juliana of the Netherlands.

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[devzero at web.de]

pardon, that was not my intention, nor was it my intention to infringe list rules.  so, this is for developers/experts - not for users and bug-reporters?

i`m spending more than half of this evening with this issue, trying to find a solution and trying to provide information for a problem affecting many people and which seems to exist in u-boot.

so please forgive if i jumped onto the  wrong thread as an entry point and i helter-skelter blundered into this list. will go whine elsewhere then and use obscure workarounds for this issue instead ( like that guy on this thread: http://openplug.org/plugforum/index.php?topic=131.0 )

regards
roland


----Urspr?ngliche Nachricht-----
Von: "Wolfgang Denk" <wd@denx.de>
Gesendet: 20.09.2010 23:19:15
An: "Roland Kletzing" <devzero@web.de>
Betreff: Re: [U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

>Dear "Roland Kletzing",
>
>In message <9714EDEC3798462FACB91473A96284B8@samsungnetbook> you wrote:
>> 
>> i`m searching for a solution for a while, so i`m trying my luck here. I`m 
>> using Seagate Dockstar (ARM926EJ-S based) NAS device and installed Debian 
>> ARM on that as documented at http://jeff.doozan.com/debian/
>
>You hijack a (pretty much unrelated) mail thread.
>
>You top-post.
>
>You full-quote.
>
>And it seems you did not read neither
>http://www.netmeister.org/news/learn2quote.html  nor
>http://www.catb.org/~esr/faqs/smart-questions.html
>
>
>
>I think your problem is completely unrelated to the Subject: you refer
>to.
>
>Best regards,
>
>Wolfgang Denk
>
>-- 
>DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
>I can't understand it. I can't even understand  the  people  who  can
>understand it.                    - Queen Juliana of the Netherlands.
___________________________________________________________
Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!  
Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Wolfgang Denk]

Dear devzero at web.de,

In message <899533205.349626.1285022229052.JavaMail.fmail@mwmweb063> you wrote:
> pardon, that was not my intention, nor was it my intention to infringe list
>  rules.  so, this is for developers/experts - not for users and bug-reporte
> rs?

This list is for ALL discussions about U-Boot: users, bug-reporters,
developers, etc.

But we expect that everybody who posts here follows some basic
Netiquette.

You don't. For example, Netiquette says to keep your line length below
some 70 characters or so.

You don't even after being told.  I asked you explicitly NOT to top
post / full quote, and pointed you to rules for correct quoting. You
ignore that.

> i`m spending more than half of this evening with this issue, trying to find
>  a solution and trying to provide information for a problem affecting manyr
> people and which seems to exist in u-boot.

I also pointed you to a document that explains how to ask smart
questions, but it seems you ignored this hint as well.

You completely fail to explain which exact version of U-Boot you are
running - it seems to be a locally modified one, probably with
out-of-tree patches to support that Dockstar board which is not known
in the mainline U-Boot repository.  How should we be able to comment
on code we don't even know?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Have you lived in this village all your life?"        "No, not yet."

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Detlev Zundel]

Hi Roland,

> i`m spending more than half of this evening with this issue, trying to
> find a solution and trying to provide information for a problem
> affecting many people and which seems to exist in u-boot.

Rest assured that many people on this list spend multiple days with USB
problems :|

> so please forgive if i jumped onto the wrong thread as an entry point
> and i helter-skelter blundered into this list. will go whine elsewhere
> then and use obscure workarounds for this issue instead ( like that
> guy on this thread:
> http://openplug.org/plugforum/index.php?topic=131.0 )

The guy doing a reboot when it fails?  Actually not a bad strategy.  It
shows once more that USB has the tendency to be non-deterministic.

As always, it would be good to first find out if the codebase of the
U-Boot you use is comparable to mainline (otherwise we cannot use _any_
tests you do) and then do systematic tests to narrow down the problem.

It may well be that USB has been tested better in U-Boot context with
USB sticks (solid state) rather than mechainically spinning hard disks.
Maybe this is something which needs to be taken into account in the
code.

Keep us posted.

Cheers
  Detlev

-- 
Basically,  Barnes & Noble separates things by how old they are  -- current
stuff is "Fiction", stuff from 20 years ago is "Literature", stuff from 100
years ago is "Classics", stuff from 400 years ago is "Shakespeare" [..] and
stuff from 2000 years ago is "History".
                     -- James "Kibo" Parry in <kibo-1207032212000001@10.0.1.2>
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[devzero at web.de]

Hello Detlev, 

>> i`m spending more than half of this evening with this issue, trying to
>> find a solution and trying to provide information for a problem
>> affecting many people and which seems to exist in u-boot.
>
>Rest assured that many people on this list spend multiple days with USB
>problems :|

Ok, we know that from linux..... :(

>> so please forgive if i jumped onto the wrong thread as an entry point
>> and i helter-skelter blundered into this list. will go whine elsewhere
>> then and use obscure workarounds for this issue instead ( like that
>> guy on this thread:
>> http://openplug.org/plugforum/index.php?topic=131.0 )
>
>The guy doing a reboot when it fails?  Actually not a bad strategy.  It
>shows once more that USB has the tendency to be non-deterministic.

Yes, but for my setup unfortunately neither reboot (i.e. warm-boot) helps, 
nor does it help to add pre-boot usb reset to the u-boot config.

>As always, it would be good to first find out if the codebase of the
>U-Boot you use is comparable to mainline (otherwise we cannot use _any_
>tests you do) and then do systematic tests to narrow down the problem.

See my other posting.

>It may well be that USB has been tested better in U-Boot context with
>USB sticks (solid state) rather than mechainically spinning hard disks.
>Maybe this is something which needs to be taken into account in the
>code.
That`s a good theory. 
btw, iirc, i saw some hint that the code (usb-storage.c !?) that it had only 
been well tested with flash media.

Anyway, just to tell about the background:
I`m trying to replace my home server with a Dockstar. As this runs 24/7 
i want something energy-efficient for that.
I got some Dockstars for so cheap and they are asbolute fantastic and 
just perfect fit to be run with debian. I plan buying a solid state sata disk 
with sata2usb one day, but seeing two ordinary disks with 2 different ide2usb 
fail does not encourage me to spend bucks on something new. I want a robust 
system where i can use more than "some" drives which are just compatible by 
chance. From what i have tested, the debian install on dockstar runs pretty well, 
stable and fast.

regards
Roland
___________________________________________________________
GRATIS: Spider-Man 1-3 sowie 300 weitere Videos!
Jetzt kostenlose Movie-FLAT freischalten! http://movieflat.web.de

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Detlev Zundel]

Hi Roland,

[...]

> Anyway, just to tell about the background:
> I`m trying to replace my home server with a Dockstar. As this runs 24/7 
> i want something energy-efficient for that.
> I got some Dockstars for so cheap and they are asbolute fantastic and 
> just perfect fit to be run with debian. I plan buying a solid state sata disk 
> with sata2usb one day, but seeing two ordinary disks with 2 different ide2usb 
> fail does not encourage me to spend bucks on something new. I want a robust 
> system where i can use more than "some" drives which are just compatible by 
> chance. From what i have tested, the debian install on dockstar runs pretty well, 
> stable and fast.

In my personal experience, "robust" and "usb" do not mix well in one
sentence.  Maybe I'm somewhat conservative, but just in another product
I have seen spurious USB dis- and reconnects after days and weeks of
otherwise solid functioning.  Of course they _did_ mess up the software
and crash the system.  So be sure that your software stack can cope with
something like that.

In effect, currently I would not try to design a "robust system" (ready
to be sold as a product) with its primary rootfilesystem on a USB
storage device.  For IDE/ATA/SATA all the problems in a running system
that I have seen have had their cause in the device, not in the
interconnect method.  This is not something I can say about USB.

Cheers
  Detlev

-- 
error compiling committee.c: too many arguments to function
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Roland Kletzing]

Good evening !

Some new (real weird) findings i like to report.

I have tried a third usb2ide adapter cable of different brand.
Had that around at work....

Apparently , it uses exactly the same jmicron chipset as one of the
other ones which fail - but this one - surprise - WORKS !
The output of "usb info" is exactly the same. Where the former one
fails with "usb part" , this one works with "usb part" and gives proper
info and i can boot without a problem. Loading kernel & initrd is slow,
but it works, even with cold boot.

So, i`m wondering who`s to blame - the cable or the sofware, or both :)

Since both cables work with linux, maybe there is some slight differenc
in pcb/cable design and thus some slight timing difference which causing
this problem.

Maybe i will go to find some more convertor cables, just for curiousity
and to see how they behave. Does someone know a website listing usb
convertor cables and compare their "quality" ? I did not find such....

Anyway, so my problem is not that serious anymore, as i know the
hardware is part of the problem and which can be replaced.....

regards
roland



Marvell>> usb info
usb info
1: Hub,  USB Revision 2.0
 - u-boot EHCI Host Controller
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x0000  Product 0x0000 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 0mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 8 Interval 255ms

2: Hub,  USB Revision 2.0
 -  USB2.0 Hub
 - Class: Hub
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x05e3  Product 0x0608 Version 6.3
   Configuration: 1
   - Interfaces: 1 Self Powered Remote Wakeup 100mA
     Interface: 0
     - Alternate Setting 0, Endpoints: 1
     - Class Hub
     - Endpoint 1 In Interrupt MaxPacket 1 Interval 12ms

3: Mass Storage,  USB Revision 2.0
 - JMicron USB to ATA/ATAPI Bridge 222222126873
 - Class: (from Interface) Mass Storage
 - PacketSize: 64  Configurations: 1
 - Vendor: 0x152d  Product 0x2338 Version 1.0
   Configuration: 1
   - Interfaces: 1 Self Powered 2mA
   - String: "USB Mass Storage"
     Interface: 0
     - Alternate Setting 0, Endpoints: 2
     - Class Mass Storage, Transp. SCSI, Bulk only
     - String: "MSC Bulk-Only Transfer"
     - Endpoint 1 In Bulk MaxPacket 512
     - Endpoint 2 Out Bulk MaxPacket 512

Marvell>> usb storage
usb storage
  Device 0: Vendor: HITACHI_ Rev: A0A5 Prod: DK14FA-20
            Type: Hard Disk
            Capacity: 19077.1 MB = 18.6 GB (39070080 x 512)

usb part

Partition Map for USB device 0  --   Partition Type: DOS

Partition     Start Sector     Num Sectors     Type
    1                   63         4016187      83
    2              4016250          514080      82





--------------------------------------------------
From: "Detlev Zundel" <dzu@denx.de>
Sent: Thursday, September 23, 2010 11:24 AM
To: <devzero@web.de>
Cc: "Wolfgang Denk" <wd@denx.de>; <u-boot@lists.denx.de>
Subject: Re: [U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub 
and Toshiba USB stick

> Hi Roland,
>
> [...]
>
>> Anyway, just to tell about the background:
>> I`m trying to replace my home server with a Dockstar. As this runs 24/7
>> i want something energy-efficient for that.
>> I got some Dockstars for so cheap and they are asbolute fantastic and
>> just perfect fit to be run with debian. I plan buying a solid state sata 
>> disk
>> with sata2usb one day, but seeing two ordinary disks with 2 different 
>> ide2usb
>> fail does not encourage me to spend bucks on something new. I want a 
>> robust
>> system where i can use more than "some" drives which are just compatible 
>> by
>> chance. From what i have tested, the debian install on dockstar runs 
>> pretty well,
>> stable and fast.
>
> In my personal experience, "robust" and "usb" do not mix well in one
> sentence.  Maybe I'm somewhat conservative, but just in another product
> I have seen spurious USB dis- and reconnects after days and weeks of
> otherwise solid functioning.  Of course they _did_ mess up the software
> and crash the system.  So be sure that your software stack can cope with
> something like that.
>
> In effect, currently I would not try to design a "robust system" (ready
> to be sold as a product) with its primary rootfilesystem on a USB
> storage device.  For IDE/ATA/SATA all the problems in a running system
> that I have seen have had their cause in the device, not in the
> interconnect method.  This is not something I can say about USB.
>
> Cheers
>  Detlev
>
> -- 
> error compiling committee.c: too many arguments to function
> --
> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de 

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Detlev Zundel]

Hi Roland,

[...]

> I have tried a third usb2ide adapter cable of different brand.
> Had that around at work....
>
> Apparently , it uses exactly the same jmicron chipset as one of the
> other ones which fail - but this one - surprise - WORKS !

Just as an additional datapoint - we have also seen usb sticks which
by all available markings looked to contain the exact same silicon.
Only persistent questioning of the manufacturer in the end showed that
"harmless changes" were done and were deemed not important enough to be
marked by changing serial-numbers or other visible identification.

> The output of "usb info" is exactly the same. Where the former one
> fails with "usb part" , this one works with "usb part" and gives proper
> info and i can boot without a problem. Loading kernel & initrd is slow,
> but it works, even with cold boot.
>
> So, i`m wondering who`s to blame - the cable or the sofware, or both :)

I still blame the inventors of USB.  One of them is even depicted as a
rock star in an Intel ad - ugh.  I wonder what a short film with some
actual USB developers would look like :)

> Since both cables work with linux, maybe there is some slight differenc
> in pcb/cable design and thus some slight timing difference which causing
> this problem.
>
> Maybe i will go to find some more convertor cables, just for curiousity
> and to see how they behave. Does someone know a website listing usb
> convertor cables and compare their "quality" ? I did not find such....

Did you try http://www.qbik.ch/usb/devices/ ?

> Anyway, so my problem is not that serious anymore, as i know the
> hardware is part of the problem and which can be replaced.....

See, that's another reason why we still have such problems - once a
hardware replacement is found, the problem is no longer pursued.  

Note that this is a not meant as a criticism, but simply as an
explanation of the current state of affairs - I've seen this multiple
times now.

Cheers
  Detlev

[1] http://www.shoppingblog.com/blog/517099

-- 
Als ich entf?hrt wurde, begannen meine Eltern aktiv zu werden.
Sie vermieteten mein Zimmer.
                                        -- Woody Allen
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Roland Kletzing]

hi,

>> Maybe i will go to find some more convertor cables, just for curiousity
>> and to see how they behave. Does someone know a website listing usb
>> convertor cables and compare their "quality" ? I did not find such....
>
> Did you try http://www.qbik.ch/usb/devices/ ?

great link, thanks !

> See, that's another reason why we still have such problems - once a
> hardware replacement is found, the problem is no longer pursued.

Oh, have a look on the linux bugtracker or other linux communities.
I have seen so many problems go away by hardware replacement
("sorry, i can`t reproduce the problem, i gave back the mobo and bought
a new one...."). But even more problems were not solved because either
nobody cared or nobody cared soon enough.....

Anyway, i found one of the problematic USB bridge cables being problematic
on my new netbook, too (disk not being recognized), so i assume it`s really
crap and my 2 failing setups are mostly due to bad hardware. I will keep an
eye on that and report my findings, if appreciated.

regards
roland 

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Detlev Zundel]

Hi Roland,

[...]

>> See, that's another reason why we still have such problems - once a
>> hardware replacement is found, the problem is no longer pursued.
>
> Oh, have a look on the linux bugtracker or other linux communities.

USB support in Linux is way better than what we have in U-Boot and thats
what I was talking about.

> Anyway, i found one of the problematic USB bridge cables being problematic
> on my new netbook, too (disk not being recognized), so i assume it`s really
> crap and my 2 failing setups are mostly due to bad hardware. I will keep an
> eye on that and report my findings, if appreciated.

Of course this is appreciated!  Many samples in the "experince space"
are important information for developers.  Although we usually only see
the "it doesn't work" samples, some "hey it works!" would also not hurt
;)

Cheers
  Detlev

-- 
If you currently have a 32-bit UNIX system, you are advised to
trade it in for a 64-bit one sometime before the year 2106.
 -- Andrew S. Tanenbaum: Modern Operating Systems, 2nd Edition
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Wolfgang Denk]

Dear Remy,

In message <1283280314-10700-1-git-send-email-agust@denx.de> Anatolij
Gustschin wrote:
> Checking the status field of the qTD token in the current code
> do not take into acount cases where endpoint stall (halted) bit
> is set together with some other status bits. As a result clearing
> stall on an endpoint won't be done if other status bits were set.
> 
> E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
> connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
> issue showed that while bulk IN transfers with length of 13 or
> 18 the status field of the qTD token sometimes indicates trans-
> action error (XactErr) and sometimes additionally endpoint halted
> state. In the latter case resetting the USB device in error
> recovery code fails as no clear stall request on the endpoint
> will be done. The patch fixes status field checking code to
> properly handle endpoint halted state.
> 
> However this fix is not enough to solve 'usb start' problem
> with hub/stick combination mentioned above. Running with lot of
> debug code in ehci_submit_async() I've never seen the problem
> with usb stick recognition. After removing this debug code the
> similar problem sometimes showed up again. Therefore the patch
> also adds delay in ehci_submit_async() for above-mentioned
> hub/stick combination. Even without this delay the fix is an
> improvement since it fixes the problem with board freezy after
> subsequent failed 'usb start/stop' cycles as it was observed
> on mpc5121ads board.
> 
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
>  common/usb_storage.c        |    5 +++--
>  drivers/usb/host/ehci-hcd.c |    8 ++++++++
>  2 files changed, 11 insertions(+), 2 deletions(-)

Any comments on this?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A little retrospection shows that although many fine, useful software
systems have been  designed  by  committees  and  built  as  part  of
multipart  projects, those software systems that have excited passio-
nate fans are those that are the products of one or a  few  designing
minds,  great  designers.  Consider  Unix,  APL,  Pascal, Modula, the
Smalltalk interface, even Fortran;  and  contrast  them  with  Cobol,
PL/I, Algol, MVS/370, and MS-DOS.                  - Fred Brooks, Jr.

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Remy Bohmer]

Hi,

2010/10/12 Wolfgang Denk <wd@denx.de>:
> Dear Remy,
>
> In message <1283280314-10700-1-git-send-email-agust@denx.de> Anatolij
> Gustschin wrote:
>> Checking the status field of the qTD token in the current code
>> do not take into acount cases where endpoint stall (halted) bit
>> is set together with some other status bits. As a result clearing
>> stall on an endpoint won't be done if other status bits were set.
>>
>> <snip>
>>
>> Signed-off-by: Anatolij Gustschin <agust@denx.de>
>> ---
>> ?common/usb_storage.c ? ? ? ?| ? ?5 +++--
>> ?drivers/usb/host/ehci-hcd.c | ? ?8 ++++++++
>> ?2 files changed, 11 insertions(+), 2 deletions(-)
>
> Any comments on this?

I had, look here:
http://lists.denx.de/pipermail/u-boot/2010-September/076537.html
It is silence on this patch since.

Kind regards,

Remy

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Wolfgang Denk]

Dear Anatolij,

In message <AANLkTikbnmdtJNCjd-pjeHWsw+Ng8sTF1iZT1utG6JS8@mail.gmail.com> Remy Bohmer wrote:
> Hi,
> 
> 2010/8/31 Anatolij Gustschin <agust@denx.de>:
> > Checking the status field of the qTD token in the current code
> > do not take into acount cases where endpoint stall (halted) bit
> > is set together with some other status bits. As a result clearing
> > stall on an endpoint won't be done if other status bits were set.
> 
> Reading this description and this code:
> 
> >        /* special handling of STALL in DATA phase */
> > -       if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
> > +       if ((result < 0) &&
> > +           (us->pusb_dev->status & (USB_ST_STALLED | USB_ST_CRC_ERR))) {
> >                USB_STOR_PRINTF("DATA:stall\n");
> 
> Description and code do not seem to match. The old implementation
> explicitly checked if the STALLED bit was set, and if so the endpoint
> would be cleared. Now, it seems you are clearing the endpoint _also_
> when the CRC_ERR bit is set.
> 
> There are a lot more reasons, at least on other host controllers that
> set the status USB_ST_CRC_ERR, does this change not break the other
> code? (A simple grep will show you the situations where it is
> returned.)
> 
> > E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
> > connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
> > issue showed that while bulk IN transfers with length of 13 or
> > 18 the status field of the qTD token sometimes indicates trans-
> > action error (XactErr) and sometimes additionally endpoint halted
> > state. In the latter case resetting the USB device in error
> > recovery code fails as no clear stall request on the endpoint
> > will be done.
> 
> OK
> 
> > However this fix is not enough to solve 'usb start' problem
> > with hub/stick combination mentioned above. Running with lot of
> > debug code in ehci_submit_async() I've never seen the problem
> > with usb stick recognition. After removing this debug code the
> > similar problem sometimes showed up again. Therefore the patch
> > also adds delay in ehci_submit_async() for above-mentioned
> > hub/stick combination. Even without this delay the fix is an
> 
> Why only for these USB sticks? Are these sticks special among the
> thousands of different sticks out there?
> Or could it be more reliable to always do this delay for all USB
> sticks? Or even better, what are we missing here that the delay is
> needed at all?
> 
> > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> > index 37d056e..7463a75 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> 
> Is this problem only valid for the EHCI code? I can imagine that the
> other host controllers (like UHCI and OHCI and so on) code suffer the
> same problem and need similar fixes...
> (At least I know that I have here a couple of USB sticks that show
> similar problems with OHCI ;-) )


As far as I can tell you never replied to thesequestions, with the
result that this patch did not make it into mainline yet.

Could you please have a look?  Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
An expert is a person who avoids the small errors while  sweeping  on
to the grand fallacy.

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Anatolij Gustschin]

Hi Remy,

On Wed, 1 Sep 2010 10:49:22 +0200
Remy Bohmer <linux@bohmer.net> wrote:
...
> 2010/8/31 Anatolij Gustschin <agust@denx.de>:
> > Checking the status field of the qTD token in the current code
> > do not take into acount cases where endpoint stall (halted) bit
> > is set together with some other status bits. As a result clearing
> > stall on an endpoint won't be done if other status bits were set.
> 
> Reading this description and this code:
> 
> >        /* special handling of STALL in DATA phase */
> > -       if ((result < 0) && (us->pusb_dev->status &
> > USB_ST_STALLED)) {
> > +       if ((result < 0) &&
> > +           (us->pusb_dev->status & (USB_ST_STALLED |
> > USB_ST_CRC_ERR))) { USB_STOR_PRINTF("DATA:stall\n");
> 
> Description and code do not seem to match. The old implementation
> explicitly checked if the STALLED bit was set, and if so the endpoint
> would be cleared. Now, it seems you are clearing the endpoint _also_
> when the CRC_ERR bit is set.

Yes. This was intentional but unfortunately not directly mentioned
in the patch description. The reason is the following:

in all cases where transaction error (XactErr) was reported with
additionally STALLED bit set, the handling of the STALL condition
successfully recovered from the error case and the device was
recognized.

in cases where only transaction error was reported (STALLED bit
not set) the recovery from the error case didn't succeed and
"Device NOT ready" (Request Sense returned 06 28 00) status was
finally reported. I didn't find the information in the EHCI spec
how the recovery from the XactErr should be done properly. Do
you know how to handle it?

> There are a lot more reasons, at least on other host controllers that
> set the status USB_ST_CRC_ERR, does this change not break the other
> code? (A simple grep will show you the situations where it is
> returned.)

This change will probably break other code. I'll drop it here and
additionally set USB_ST_STALLED flag in the ehci driver instead.

> > E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
> > connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
> > issue showed that while bulk IN transfers with length of 13 or
> > 18 the status field of the qTD token sometimes indicates trans-
> > action error (XactErr) and sometimes additionally endpoint halted
> > state. In the latter case resetting the USB device in error
> > recovery code fails as no clear stall request on the endpoint
> > will be done.
> 
> OK
> 
> > However this fix is not enough to solve 'usb start' problem
> > with hub/stick combination mentioned above. Running with lot of
> > debug code in ehci_submit_async() I've never seen the problem
> > with usb stick recognition. After removing this debug code the
> > similar problem sometimes showed up again. Therefore the patch
> > also adds delay in ehci_submit_async() for above-mentioned
> > hub/stick combination. Even without this delay the fix is an
> 
> Why only for these USB sticks? Are these sticks special among the
> thousands of different sticks out there?

I do not have the right equipment to analyze this problem properly.
This is the special USB stick-hub combination. The same USB stick
is always recognized properly if it is connected directly. Other
USB sticks also work with this USB hub.

> Or could it be more reliable to always do this delay for all USB
> sticks? Or even better, what are we missing here that the delay is
> needed at all?

Doing this delay for other USB sticks will negatively affect data
transfer speed.

> > diff --git a/drivers/usb/host/ehci-hcd.c
> > b/drivers/usb/host/ehci-hcd.c index 37d056e..7463a75 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> 
> Is this problem only valid for the EHCI code? I can imagine that the
> other host controllers (like UHCI and OHCI and so on) code suffer the
> same problem and need similar fixes...
> (At least I know that I have here a couple of USB sticks that show
> similar problems with OHCI ;-) )

Maybe, maybe not. The problem shows up on SheevaPlug and mpc5121ads
boards, both using USB EHCI. I do not have the possibility to test
it on other host controllers currently.

Best regards,
Anatolij

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Remy Bohmer]

Hi,

2010/10/27 Anatolij Gustschin <agust@denx.de>:
> Hi Remy,
>
> On Wed, 1 Sep 2010 10:49:22 +0200
> Remy Bohmer <linux@bohmer.net> wrote:
> ...
>> 2010/8/31 Anatolij Gustschin <agust@denx.de>:
>> > Checking the status field of the qTD token in the current code
>> > do not take into acount cases where endpoint stall (halted) bit
>> > is set together with some other status bits. As a result clearing
>> > stall on an endpoint won't be done if other status bits were set.
>>
>> Reading this description and this code:
>>
>> > ? ? ? ?/* special handling of STALL in DATA phase */
>> > - ? ? ? if ((result < 0) && (us->pusb_dev->status &
>> > USB_ST_STALLED)) {
>> > + ? ? ? if ((result < 0) &&
>> > + ? ? ? ? ? (us->pusb_dev->status & (USB_ST_STALLED |
>> > USB_ST_CRC_ERR))) { USB_STOR_PRINTF("DATA:stall\n");
>>
>> Description and code do not seem to match. The old implementation
>> explicitly checked if the STALLED bit was set, and if so the endpoint
>> would be cleared. Now, it seems you are clearing the endpoint _also_
>> when the CRC_ERR bit is set.
>
> Yes. This was intentional but unfortunately not directly mentioned
> in the patch description. The reason is the following:
>
> in all cases where transaction error (XactErr) was reported with
> additionally STALLED bit set, the handling of the STALL condition
> successfully recovered from the error case and the device was
> recognized.
>
> in cases where only transaction error was reported (STALLED bit
> not set) the recovery from the error case didn't succeed and
> "Device NOT ready" (Request Sense returned 06 28 00) status was
> finally reported. I didn't find the information in the EHCI spec
> how the recovery from the XactErr should be done properly. Do
> you know how to handle it?
>
>> There are a lot more reasons, at least on other host controllers that
>> set the status USB_ST_CRC_ERR, does this change not break the other
>> code? (A simple grep will show you the situations where it is
>> returned.)
>
> This change will probably break other code. I'll drop it here and
> additionally set USB_ST_STALLED flag in the ehci driver instead.

OK. I will ignore this version of this patch. I assume you will post a
new revision of this patch?

Kind regards,

Remy

[U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick

[Anatolij Gustschin]

Hi,

On Fri, 29 Oct 2010 15:57:54 +0200
Remy Bohmer <linux@bohmer.net> wrote:
...
> > in cases where only transaction error was reported (STALLED bit
> > not set) the recovery from the error case didn't succeed and
> > "Device NOT ready" (Request Sense returned 06 28 00) status was
> > finally reported. I didn't find the information in the EHCI spec
> > how the recovery from the XactErr should be done properly. Do
> > you know how to handle it?
> >
> >> There are a lot more reasons, at least on other host controllers that
> >> set the status USB_ST_CRC_ERR, does this change not break the other
> >> code? (A simple grep will show you the situations where it is
> >> returned.)
> >
> > This change will probably break other code. I'll drop it here and
> > additionally set USB_ST_STALLED flag in the ehci driver instead.
> 
> OK. I will ignore this version of this patch. I assume you will post a
> new revision of this patch?

Yes, my intention is to post v2 patch.

Thanks,
Anatolij