Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi, 2010/11/25 Anatolij Gustschin ag...@denx.de: Hi Remy, On Tue, 02 Nov 2010 21:46:33 +0100 Wolfgang Denk w...@denx.de wrote: Dear Remy Bohmer, In message aanlktik0bxxfe8d5+96gy_=+cu0h_fkeyutfyo=cr...@mail.gmail.com you wrote: As U-boot project-owner you know you have the last word in this. This is a pretty precious resource that should be used wisely, and not without real need. This topic is clearly in your domain, and while I'm trying to explain the situation to you, I will not try to influence your decision. I just wanted to ask, what is your final decision on this patch after this discusion. Do you NACK it an we should find the real issue and fix it accordingly? Or can you accept this patch as is? Sorry, but I stand with my decision to NACK it. If we would allow these kind of patches, U-boot would be fluttered in no-time with all kinds of exceptions all over the place to hide bugs not really understood. What if someone else runs into the same bug in a different hardware setup and finds the real root-cause of that problem and posts a real fix. When do we know that this workaround can be removed? It would probably stay in there for years and nobody knows what to do with it... Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi Remy, On Tue, 02 Nov 2010 21:46:33 +0100 Wolfgang Denk w...@denx.de wrote: Dear Remy Bohmer, In message aanlktik0bxxfe8d5+96gy_=+cu0h_fkeyutfyo=cr...@mail.gmail.com you wrote: As U-boot project-owner you know you have the last word in this. This is a pretty precious resource that should be used wisely, and not without real need. This topic is clearly in your domain, and while I'm trying to explain the situation to you, I will not try to influence your decision. I just wanted to ask, what is your final decision on this patch after this discusion. Do you NACK it an we should find the real issue and fix it accordingly? Or can you accept this patch as is? How do you think how to continue from here? I don't really know. There should be a difference in controlling the devices triggering the bug, and without hispeed analyser it will be extremely hard to find. We have one here, but we do not have your boards, USB hub/devices and so on. (And... neither do I have the time to debug it for you...) Nobody expects that you spend time and resources (and for free) on such a pretty exotic issue. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Dear Anatolij, In message 20101125111729.3ce4f...@wker you wrote: I just wanted to ask, what is your final decision on this patch after this discusion. Do you NACK it an we should find the real issue and fix it accordingly? Or can you accept this patch as is? I'm afraid we have neither time nor resources to spend any significant efforts on this - from the customer's point of view the problem is solved. He is fine with the out-of-tree patch, but of course this is highly dissatisfying. 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: w...@denx.de Look! There! Evil!.. pure and simple, total evil from the Eighth Dimension! - Buckaroo Banzai ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi, 2010/11/2 Anatolij Gustschin ag...@denx.de: 'usb start' command 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 handling code works after clearing stall request on the endpoint. In the case where only XactErr bit was set the resetting doesn't work properly and device not ready status will be finally reported. This patch adds reporting endpoint stall status in case of trans- action errors for this hub/stick combination so that the error handling code can reset the device after clearing stall request to the endpoint. 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 ag...@denx.de --- drivers/usb/host/ehci-hcd.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index c7fba10..a001143 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -431,6 +431,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); + I have to say that I have a problem with this construction. This will solve only 1 particular situation where the user has exactly this USB stick and exactly this hub. If he uses another hub, he can have the same problem. If he use another USB-stick he also can run into this problem. What is the real cause of this issue, and can it be solved in a generic way? I feel the problem is still not understood. So, I NAK this patch.. Sorry... Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Dear Remy Bohmer, In message aanlktikqeftb=xeav1g6xyvoy3hw3imcpifild0kv...@mail.gmail.com you wrote: + if (dev-descriptor.idVendor == 0x930 + dev-descriptor.idProduct == 0x6545 + dev-parent-descriptor.idVendor == 0x424 + dev-parent-descriptor.idProduct == 0x2514) + wait_ms(10); + I have to say that I have a problem with this construction. This will solve only 1 particular situation where the user has exactly this USB stick and exactly this hub. If he uses another hub, he can have the same problem. If he use another USB-stick he also can run into this problem. What is the real cause of this issue, and can it be solved in a generic way? I feel the problem is still not understood. Indeed the problem is not exactly understood. Anatolij has tested a wide range of board / hub / stick combinations, and the problem happens only with this very combination. Yes, there is a chance that another hub / stick combination might show similar issues, but so far we have not been able to find such another combo. So, I NAK this patch.. Sorry... So what do you propose to solve the problem? Of course we could add the delay unconditionally, for all systems. But it brings with it a performance degradation which I would not like to see either. What do you suggest to provide a solution for this specific situation? 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: w...@denx.de Wisdom is one of the few things that looks bigger the further away it is. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi Wolfgang, 2010/11/2 Wolfgang Denk w...@denx.de: Dear Remy Bohmer, In message aanlktikqeftb=xeav1g6xyvoy3hw3imcpifild0kv...@mail.gmail.com you wrote: + if (dev-descriptor.idVendor == 0x930 + dev-descriptor.idProduct == 0x6545 + dev-parent-descriptor.idVendor == 0x424 + dev-parent-descriptor.idProduct == 0x2514) + wait_ms(10); + I have to say that I have a problem with this construction. This will solve only 1 particular situation where the user has exactly this USB stick and exactly this hub. If he uses another hub, he can have the same problem. If he use another USB-stick he also can run into this problem. What is the real cause of this issue, and can it be solved in a generic way? I feel the problem is still not understood. Indeed the problem is not exactly understood. Anatolij has tested a wide range of board / hub / stick combinations, and the problem happens only with this very combination. Yes, there is a chance that another hub / stick combination might show similar issues, but so far we have not been able to find such another combo. So, I NAK this patch.. Sorry... So what do you propose to solve the problem? Of course we could add the delay unconditionally, for all systems. But it brings with it a performance degradation which I would not like to see either. Agreed What do you suggest to provide a solution for this specific situation? I have no idea what has been done, and has not been done. I have not been debugging this issue. I have no idea if a USB protocol analyser has shown something weird or something we could work on. But anyway: You admit that the problem is not understood, so would the delay fix the problem, or just make it less obvious? If we would allow such workarounds to U-boot we would end up with endless lists of device-ids that are excluded in some situation all over the place. The code would just become fluttered with all kinds of exceptions to mask problems not being understood and not being debugged properly. And in this case: How big is the chance that any other user will have exact the same hardware combination and run into this problem? I guess that would be close to zero... My guts tells me that the chance that other combinations require the same 'fix' is bigger... If it is proven to be a bug of a specific device, that would change the situation, in that case we would work-around a certain device bug that really cannot be solved otherwise. In that case we would _know_ what problem we are working around, and that would be a limited of devices and situations. We at least could document it. So, I need more info to convince me that this is the right solution. Does, for example, Linux have similar issues? If not, why is it working there. Does a protocol analyser show different behaviour, different timing, different data? What is different? Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Dear Remy, In message aanlktimtzosbtobm_og304gbrcpcm1wjet0xqo+mg...@mail.gmail.com you wrote: I have no idea what has been done, and has not been done. I have not been debugging this issue. I have no idea if a USB protocol analyser has shown something weird or something we could work on. Sorry - we don;t have a USB protocol analyzer that does high-speed. So our debugging is mostly limited to what we can see in the controller, and in the software levels above it. But anyway: You admit that the problem is not understood, so would the delay fix the problem, or just make it less obvious? You know that I cannot really answer this question. Without exact understanding what is going on it is just a pretty much dirty work around. It helps in this specific test case, but we have zero knowledge if it helps in opther cases, and what these cases may be. The interesting part of these tests was that the problem really sticks to one specific combination of hub and storage device. If we would allow such workarounds to U-boot we would end up with endless lists of device-ids that are excluded in some situation all over the place. The code would just become fluttered with all kinds of exceptions to mask problems not being understood and not being debugged properly. Agreed. And in this case: How big is the chance that any other user will have exact the same hardware combination and run into this problem? I guess that would be close to zero... My guts tells me that the chance that other combinations require the same 'fix' is bigger... I am positive sure that other uses with this hardware combination _will_ run into the same problem. This fix was developed for a customer who needed it pretty much urgently because he was using this combo in numbers where he preferred paying for the fix over throwing away the sticks and.or hubs and using other models. The problem was reliablew repeatable on all his devices. And we saw it on PowerPC (MPC5121) and ARM (Kirkwood). That's why I'm pretty sure that it whill hit if you run such a combo. If it is proven to be a bug of a specific device, that would change the situation, in that case we would work-around a certain device bug that really cannot be solved otherwise. In that case we would _know_ what problem we are working around, and that would be a limited of devices and situations. We at least could document it. Unfortunately we can only point at the combo of devices - each for itself appears to be working OK. So, I need more info to convince me that this is the right solution. Does, for example, Linux have similar issues? If not, why is it No, we did not observe such problems under Linux. We were not able to find out why. working there. Does a protocol analyser show different behaviour, different timing, different data? What is different? We don't have any such information, unfortunately. 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: w...@denx.de Bugs are by far the largest and most successful class of entity, with nearly a million known species. In this res- pect they outnumber all the other known creatures about four to one. -- Professor Snope's Encyclopedia of Animal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi, 2010/11/2 Wolfgang Denk w...@denx.de: Dear Remy, In message aanlktimtzosbtobm_og304gbrcpcm1wjet0xqo+mg...@mail.gmail.com you wrote: I have no idea what has been done, and has not been done. I have not been debugging this issue. I have no idea if a USB protocol analyser has shown something weird or something we could work on. Sorry - we don;t have a USB protocol analyzer that does high-speed. So our debugging is mostly limited to what we can see in the controller, and in the software levels above it. Hmm, then, unfortunately, you are quite blindfolded for debugging this problem... If we would allow such workarounds to U-boot we would end up with endless lists of device-ids that are excluded in some situation all over the place. The code would just become fluttered with all kinds of exceptions to mask problems not being understood and not being debugged properly. Agreed. As U-boot project-owner you know you have the last word in this. How do you think how to continue from here? And in this case: How big is the chance that any other user will have exact the same hardware combination and run into this problem? I guess that would be close to zero... My guts tells me that the chance that other combinations require the same 'fix' is bigger... I am positive sure that other uses with this hardware combination _will_ run into the same problem. This fix was developed for a customer who needed it pretty much urgently because he was using this combo in numbers where he preferred paying for the fix over throwing away the sticks and.or hubs and using other models. The problem was reliablew repeatable on all his devices. And we saw it on PowerPC (MPC5121) and ARM (Kirkwood). That's why I'm pretty sure that it whill hit if you run such a combo. Understood. If it is proven to be a bug of a specific device, that would change the situation, in that case we would work-around a certain device bug that really cannot be solved otherwise. In that case we would _know_ what problem we are working around, and that would be a limited of devices and situations. We at least could document it. Unfortunately we can only point at the combo of devices - each for itself appears to be working OK. OK So, I need more info to convince me that this is the right solution. Does, for example, Linux have similar issues? If not, why is it No, we did not observe such problems under Linux. We were not able to find out why. There should be a difference in controlling the devices triggering the bug, and without hispeed analyser it will be extremely hard to find. We have one here, but we do not have your boards, USB hub/devices and so on. (And... neither do I have the time to debug it for you...) working there. Does a protocol analyser show different behaviour, different timing, different data? What is different? We don't have any such information, unfortunately. Understood. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Dear Remy Bohmer, In message aanlktik0bxxfe8d5+96gy_=+cu0h_fkeyutfyo=cr...@mail.gmail.com you wrote: As U-boot project-owner you know you have the last word in this. This is a pretty precious resource that should be used wisely, and not without real need. This topic is clearly in your domain, and while I'm trying to explain the situation to you, I will not try to influence your decision. How do you think how to continue from here? I don't really know. There should be a difference in controlling the devices triggering the bug, and without hispeed analyser it will be extremely hard to find. We have one here, but we do not have your boards, USB hub/devices and so on. (And... neither do I have the time to debug it for you...) Nobody expects that you spend time and resources (and for free) on such a pretty exotic issue. 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: w...@denx.de Even if you aren't in doubt, consider the mental welfare of the per- son who has to maintain the code after you, and who will probably put parens in the wrong place. - Larry Wall in the perl man page ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
