Alan Stern wrote: > On Wed, 6 Jul 2011, Ed Endejan wrote: > > > Alan Stern <stern@...> writes: > > > > > Maybe the other files in that directory will be more useful. Let's see > > > what they show after the device is plugged in but before you run the > > > test program, and then again after the test program fails. > > > > > > > The other two files in that directory don't seem to add any useful info. > > > > 'async' is always blank, and 'periodic' never changes - here are the contents: > > # cat periodic > > size = 256 > > 1: qh256-0001/cde1a700 (h2 ep1in [1/0] q1 p1) > > > > But what seems to be the key indicator of the failure is the 'unlink' count > > in the 'registers' file. When it changes to non-zero, the failure has occurred. > > Can you give me some hint as to what a non-zero 'unlink' means? > > It is a count of the number of URBs that have been unlinked. This is > what you would expect to see, since your problems start when you unlink > an URB. > > > > Another great thing to do, if you can, would be to hook up a bus > > > analyzer to see what's passing between the controller and your special > > > hub. > > > > > I have run tests connected directly to a root hub port and the failure still > > occurs, so our integrated hub is not the culprit. I also have used a Beagle USB > > 480 analyzer when connected to the root hub, and when this failure occurs there > > are no obvious differences in bus traffic on a good run versus a failure, other > > than there is no traffic after the failure occurs. > > Well, that's a pretty obvious difference! It seems to indicate that > the problem is in the OMAP EHCI silicon. Sorry I'm late to this thread - I've been out of office all of June and am only catching up on list emails now. @Ed, Which OMAP board is this being tested on? It appears to be an OMAP3 device, but I'm not sure if it's a 3430 or a 3630. Are you running any heavy video/camera tests at the same time on the board? OMAP3430 devices and early OMAP3630 devices are affected by a bug that can cause a controller lockup if video/camera subsystems of the OMAP are stressed. This was fixed in OMAP3630 ES1.2. See [1] for a description of the issue. If you are affected by this bug, I'm afraid the only known way to recover is by a softreset of the host controller. Would it be possible for you to test this on a new beagleboard XM or a pandaboard (or a board with newer silicon)? Thanks, Anand [1] http://marc.info/?l=linux-usb&m=129472850014890&w=2-- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
