On Wed, 2010-03-31 at 16:08 -0400, Alan Stern wrote: > Hmm. These last two timestamps aren't what they should be. These two > URBs should have completed almost exactly 64 and 128 ms after the > preceding Iso-IN URB, i.e., near timestamps 107112443 and 107176443. > Probably the controller died first -- I can't tell because there aren't > any timestamps in your kernel log extract above. I re-did this test with timestamps in the kernel log: http://xes-inc.com/sources/debug/test-with-ehci-sched-fix1.txt http://xes-inc.com/sources/debug/test-with-ehci-sched-fix2.txt In the first case, EHCI died. In the second case, for whatever reason it survived. In both of those files I included the output from userspace, kernel log, and the usbmon trace. > Exactly what happened? Most likely we will have to make that > redefinition permanent. When I set SYNC_URBS to 3 and apply your ehci-sched fix, I get the following results: http://xes-inc.com/sources/debug/test-with-syncurbs-3.txt > Also, what happens if you eliminate the sync URBs completely (set attr > to 0 in set_format() instead of using the USB_ENDPOINT_SYNCTYPE mask)? > I'm trying to determine whether the fatal error is caused by the sync > URBs or by the data URBs. In this case, aplay actually succeeds, but EHCI still dies eventually. Full results here: http://xes-inc.com/sources/debug/test-syncurbs-disabled.txt > And what about recording instead of playing? Does recording also cause > the EHCI controller to crash? I haven't focused on recording yet, but it does appear to work fine. I haven't been able to make the EHCI controller crash while recording in the handful of attempts I just made (both with and without the sync URBs, if those are even relevant to recording). - Nate Case <ncase@xxxxxxxxxxx> -- 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
