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? > 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. Ed Endejan -- 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
