On Thu, 2010-04-01 at 17:20 -0500, Nate Case wrote: > On Thu, 2010-04-01 at 17:31 -0400, Alan Stern wrote: > > > 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. > > > > The hub certainly doesn't have to be the same, and even using a > > different USB audio codec might not make any difference. If you've got > > another one available, could you try it on both a regular PC and on the > > custom board? > > I'll try this soon. I tried today with the following setup: * Off-the-shelf PCI USB 2.0 card (VT6212 EHCI controller) * Multi-TT 2->7 hub similar to what I have on the custom card * CM-108 USB audio CODEC Though it was harder to do, I got the same "fatal error". It would not happen as reliably as my other setup, and it also *seemed* to happen more often when I tried a different USB audio CODEC. One interesting thing is that I could *NOT* get a usbmon trace of this scenario, because the failure would never happen when I was reading from /sys/kernel/debug/usb/usbmon/0u. Very elusive :) > 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(). I didn't know what I was doing honestly, but I attempted to try this today also. In short, I added a cached_sitd_list to the ehci_hcd and changed the index field of struct ehci_sitd to be an array like in struct ehci_itd. Next, I went through and tried to make the sitd functions more like the itd functions with respect to the itd list usage. I probably made all kinds of horrible mistakes, because I ended up getting errors like this: [ 33.830348] ehci_hcd 0000:07:0c.1: request bf1f49c0 would overflow (65523+16> 2048) - 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
