On Wed, 25 Aug 2004, Laurent Pinchart wrote: > Hi everybody, > > I'm trying to debug a userspace device driver (ACR30U Smart Card Reader) which > uses "simple" control transfers to send data to the device, and an input bulk > endpoint to read the response. > > An error occurs when sending the command to the device, and the kernel log > reports: > > usb 1-1: usbdev_ioctl: CONTROL > usb 1-1: control write: bRequest=00 bRrequestType=40 wValue=0000 wIndex=0000 > usb 1-1: control write: data: 02 30 31 30 36 30 31 30 31 30 37 03 > uhci_hcd 0000:00:1f.2: uhci_result_control: failed with status 400000 > [c317e240] link (0317e1b2) element (0185e080) > Element != First TD > 0: [c185e040] link (0185e080) e3 LS Length=7 MaxLen=7 DT0 EndPt=0 Dev=2, > PID=2d(SETUP) (buf=06e318c8) > 1: [c185e080] link (0185e0c0) e3 LS Stalled Length=7 MaxLen=7 DT1 EndPt=0 > Dev=2, PID=e1(OUT) (buf=064bf000) > 2: [c185e0c0] link (0185e100) e3 LS Active Length=0 MaxLen=3 DT0 EndPt=0 > Dev=2, PID=e1(OUT) (buf=064bf008) > 3: [c185e100] link (00000001) e3 LS IOC Active Length=0 MaxLen=7ff DT1 > EndPt=0 Dev=2, PID=69(IN) (buf=00000000) > > usb 1-1: usbfs: USBDEVFS_CONTROL failed cmd test rqt 64 rq 0 len 12 ret -32 > > The request looks right, but I'm having some trouble reading the qh dump. I > read the USB specifications, and understant that the request is composed of a > SETUP frame, followed by two OUT frames (12 bytes of data are too much for a > max packet size of 8 bytes), and an IN frame. The four frames are dumped, and > it seems that the device reports a Stalled condition.
The correct term is "transaction", not "frame". A transaction generally consists of more than one packet. For example, a SETUP transaction consists of a SETUP packet (sent by the host), followed by a DATA0 packet (also sent by the host), followed by an ACK packet (sent by the device). Each TD you see above corresponds to a transaction. > I don't understand the sequence of events that led to the problem. Has the > first TD (SETUP) been send ? Yes. You can tell by the fact that the Active flag isn't set. > Is the Stalled condition reported on the second > TD the result of the first or second TD ? It's a _response_ to the second TD. However, it's impossible to say what the _cause_ was -- that depends on the device. The most likely possibility is that the device didn't like the SETUP data, so a result of the first TD. In other words, this is a "protocol stall". See sections 8.4.5 and 8.5.3.4 of the USB 2.0 Specification. > Why is the Length of the SETUP > frame 7 ? In UHCI controllers, the length field stored in the TD descriptors is always one less than the actual data length. Since Setup data always has length 8, the value you see is 7. > From the USB specifications, SETUP frames consist of a PID, > followed by an address (7 bits), an endpoint (4 bits) and a CRC (8 bits), so > what is the length for ? SETUP packets consist of the things you listed. The length refers to the DATA0 packet that follows the SETUP packet. It's the length of the bRequest, bRequestType, etc. > These are probably newbie questions, but reading the USB specifications and > Linux USB stack code (I'm using a UHCI host controller, with a 2.6.7 kernel) > didn't help. > > Thanks in advance for all the help you can provide. > > Laurent Pinchart You're welcome. I hope this makes things clearer. Alan Stern ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
