Simon Gittins wrote: > I'm looking into a problem with my USB modem and have traced it to usb-ohci > (2.4.19-pre10).
Then presumably it's also in the 2.5 "ohci-hcd" too, unless it's one of the bugs that's fixed there (mostly for ED queues, not TD queues). > The problem appears to be that there is a case where the HC does not retire > a TD to the done queue. When in the 'frozen' state, the TD associated with > the usb operation is neither in the done queue, or in any of the bulk > endpoint TD lists. Despite this, the TD looks to have been processed > (td->hwCBP has been changed to 0, which according to the specs means that > the TD has been finished with, and everything else in the TD looks OK). > > How can a TD neither exist in the done queue or in any bulk endpoint list, > yet still have been processed? Could be you ran into a bug in a funky code path. Is this maybe the first or last of several TDs for that urb? Is there only that one urb using that ED, or are you using bulk queuing? How is it that you detect that case? (We've all seen plenty of buggy diagnostic code!) I'd avoid believing in silicon bugs until other cases are ruled out. (Though maybe I should ask which silicon before I say that... :) FWIW one of the changes I want to see in the 2.5 code is to make the TD list tracking a bit less convoluted. Done right, that ought to make it easy to know for sure if that's what's going on! > In a somewhat related question, why does the DO_TIMEOUTS #define exist in > usb-ohci? Don't trust that code, but feel free to debug it. It's #ifdeffed out. - Dave ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Stuff, things, and much much more. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
