On Fri, 10 Jun 2005, Martin Kessler wrote:

> Good Morning, here the requested debug output, problem finally showed up 
> at around 9pm ;-) hope this will help to trace the problem.

Here is the relevant part of the file:

- skel_ls_control_qh
    [db2f9180] link (1b2f9272) element (00000001)
      urbp == NULL
    [db2f9270] link (1b2f91b2) element (1b0db080)
     Element != First TD
      0: [db0db040] link (1b0db080) e3 LS Length=7 MaxLen=7 DT0 EndPt=0 Dev=2, 
PID=2d(SETUP) (buf=1b75b020)
      1: [db0db080] link (1b0db0c0) e3 SPD LS Active NAK Length=7ff MaxLen=7 
DT1 EndPt=0 Dev=2, PID=69(IN) (buf=1acb1100)
      2: [db0db0c0] link (00000001) e3 LS IOC Active Length=0 MaxLen=7ff DT1 
EndPt=0 Dev=2, PID=e1(OUT) (buf=00000000)
- skel_fs_control_qh
    [db2f91b0] link (1b2f91e2) element (00000001)

This means about what you might expect.  There is a length-8 IN control
URB scheduled, the SETUP packet has been sent, and the device is NAKing
the IN packet.  If anybody has attempted to unlink this URB, the attempt
hasn't filtered down to the HCD.

Alan Stern



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.  How far can you shotput
a projector? How fast can you ride your desk chair down the office luge track?
If you want to score the big prize, get to know the little guy.  
Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to