Message ID | 4E0636D0.9010107@gmail.com |
---|---|
State | Accepted |
Commit | 3ecfa9525c2d78a9a8d257a7fd664f61dd10fe21 |
Delegated to: | Remy Bohmer |
Headers | show |
Hi Joel, On 06/25/2011 10:28 PM, Joel A Fernandes wrote: > --- > Robert, Could you see if this patch solves the issue you're seeing without > increasing the timeout? The tftp session retrieves the uImage with your patch and a timeout of 5000: OMAP3 beagleboard.org # tftp 0x82000000 beagle-xm-rev-c/uImage Waiting for Ethernet connection... done. Using sms0 device TFTP from server 192.168.5.5; our IP address is 192.168.5.3 Filename 'beagle-xm-rev-c/uImage'. Load address: 0x82000000 Loading: ################################################################# ############################################################EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T ##### ###################################EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T EHCI timed out on TD - token=0x88008d80 T #EHCI timed out on TD - token=0x88008d80 T ############## done Bytes transferred = 2632196 (282a04 hex) OMAP3 beagleboard.org # Regards, Robert...fortune says today:There is no TRUTH. There is no REALITY. There is no CONSISTENCY. There are no ABSOLUTE STATEMENTS I'm very probably wrong. My public pgp key is available at: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
Hi Joel, On Sat, Jun 25, 2011 at 12:28 PM, Joel A Fernandes <agnel.joel@gmail.com> wrote: > With this, the EHCI seems to "recover" from a timeout. This is particularly > observable if you were to ping the wrong IP Address and then ping the correct > one or if there was a temporary failure during tftp sessions. > > All it takes is one timeout to disable it. If you have a noisy network (lot > of traffic), even if the traffic is not for the board, the timeouts don't occur. > > Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com> > --- > Robert, Could you see if this patch solves the issue you're seeing without > increasing the timeout? > Simon, Could this be a fix for a similar issue you were seeing with asix? Yes this is better (ASIX can recover from a timeout), but I am concerned that it carries on without reporting an error. Is that right? Should we disable async schedule and then return an error? With respect to using a bulk USB stick (some of which take 3s or more to respond to a submit) this doesn't make any difference for me. It seems to take a long time to respond the first time, so the 5s timeout seems prudent. Since this sorts out the network side we can probably skip that patch. Regards, Simon > > drivers/usb/host/ehci-hcd.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c > index 243bb39..9bfcbae 100644 > --- a/drivers/usb/host/ehci-hcd.c > +++ b/drivers/usb/host/ehci-hcd.c > @@ -464,7 +464,6 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer, > /* Check that the TD processing happened */ > if (token & 0x80) { > printf("EHCI timed out on TD - token=%#x\n", token); > - goto fail; > } > > /* Disable async schedule. */ > -- > 1.7.1 > > >
Koen grabbed some patches I added that seemed to "fix" the tftpboot and ping problem for me: https://github.com/koenkooi/u-boot or my fork @ https://github.com/kylemanna/u-boot I'd be interested to hear if adding the delay at the end of the smsc95xx init helped your problem at all. - Kyle
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 243bb39..9bfcbae 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -464,7 +464,6 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer, /* Check that the TD processing happened */ if (token & 0x80) { printf("EHCI timed out on TD - token=%#x\n", token); - goto fail; } /* Disable async schedule. */
With this, the EHCI seems to "recover" from a timeout. This is particularly observable if you were to ping the wrong IP Address and then ping the correct one or if there was a temporary failure during tftp sessions. All it takes is one timeout to disable it. If you have a noisy network (lot of traffic), even if the traffic is not for the board, the timeouts don't occur. Signed-off-by: Joel A Fernandes <agnel.joel@gmail.com> --- Robert, Could you see if this patch solves the issue you're seeing without increasing the timeout? Simon, Could this be a fix for a similar issue you were seeing with asix? drivers/usb/host/ehci-hcd.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-)