On Fri, 6 Jun 2003, Duncan Sands wrote:
> Here's the schedule. It finishes like this:
>
> [dee6e2d0] link (1ee6e212) element (18f33a50)
> 0: [d8f33a50] link (1ee6e302) e3 SPD IOC Active Length=0 MaxLen=34 DT1 EndPt=7
> Dev=2, PID=e1(OUT) (buf=193cd000)
> -- Queued QH's:
> [dee6e300] link (1ee6e212) element (18f33a80)
> 0: [d8f33a80] link (00000001) e3 SPD IOC Active Length=0 MaxLen=34 DT0 EndPt=7
> Dev=2, PID=e1(OUT) (buf=193e8000)
>
> Note how the links 1ee6e212 (i.e. link to QH at ?ee6e210) seem to be to a
> non-existant QH.
> It looks to me like these urbs have completed but haven't been retired correctly.
> Comments?
You must have had debug set to 1, because your listing did not include the
skeleton QH's. That's what's confusing you; the QH at dee6e210 is the
Terminating QH.
Your listing showed 5 URBs linked for device 2, not just 2 URBs:
ep 1-IN
ep 7-IN
ep 7-IN
ep 7-OUT
ep 7-OUT
The only one executed by the HC is the first, and it's still waiting
(marked with a NAK). The first TD for the second URB was not touched by
the HC. Maybe that's where the problem lies? Although it looks perfectly
okay to me.
Is it possible that a reserved bit was not set to 0? That wouldn't show
up in the debugging output. (Don't ask me how it could have happened.)
It might be worthwhile examining a dump made immediately after you queue
the problem-causing URB. Comparing that with the values after the HC has
halted might possibly (?) point to the source of the error.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The best
thread debugger on the planet. Designed with thread debugging features
you've never dreamed of, try TotalView 6 free at www.etnus.com.
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
