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. Alan Stern -- 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
