On Wed, 31 Mar 2010, Nate Case wrote: > 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 The resubmission should not have failed. Please repeat this test with CONFIG_USB_DEBUG enabled in the kernel. Also, you can remove the stack dump you added to ehci_irq(), and insert the following in iso_stream_schedule(): /* Tried to schedule too far into the future? */ if (unlikely(((start - now) & (mod - 1)) + span >= mod - 2 * SCHEDULE_SLOP)) { + ehci_info(ehci, "now %u next %u start %u span %u uframe %d\n", + now, next, start, span, stream->next_uframe); status = -EFBIG; goto fail; } > > 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 Everything there looks normal. I get the definite feeling that there's something wrong with your EHCI controller. Exactly the same thing works on a normal PC, right? Maybe reuse of the sitd in sitd_complete() needs to be delayed in the same way that reuse of the itd in itd_complete() is, via free_cached_itd_list(). > > 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). 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
