On Thu, 2010-04-01 at 12:16 -0400, Alan Stern wrote: > > 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(): Even though it sounds like you figured this out already, I went ahead anyway and repeated this test with USB debug enabled and your debug message. Here are the results: http://xes-inc.com/sources/debug/test-with-syncurbs-3-usb-debug.txt (yes, there are still submission errors like you'd expect based on your last e-mail) > 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? I assume so, though it's hard for me to test this with a regular PC EHCI controller (using the same hubs and audio CODECS). A controller problem doesn't seem too unlikely. > On further thought, I see what the problem is. It should work okay > with SYNC_URBS set to 2. > > With 3, let's say the first URB completes in frame N. The second URB > is scheduled for frame N+64 and the third for frame N+128. When the > first is resubmitted it will be scheduled for frame N+192, leaving the > next available slot at N+256, which is too far in the future. > > Of course, all this is irrelevant to the matter of what messes up your > EHCI controller, since the controller fails even when there are no > sync URBs. When I switch to SYNC_URBS = 2, aplay seems to work fine, and I don't see any submission errors. EHCI controller still dies for unknown reasons. Results are here: http://xes-inc.com/sources/debug/test-with-syncurbs-2.txt As you'll see, there are no real clues from the kernel log even with CONFIG_USB_DEBUG enabled. From the usbmon trace, the last iso out event happens at 48820935, then an iso input happens at ~30ms later (48850692) which is around the same time the controller dies. - 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
