On Wed, 1 Mar 2006, Marc Singer wrote: > On Wed, Mar 01, 2006 at 04:56:51PM -0800, Pete Zaitcev wrote: > > On Wed, 1 Mar 2006 16:27:56 -0800, Marc Singer <[EMAIL PROTECTED]> wrote: > > > > > 0:15.261198 # 10 S Ci 009:00 s 80 00 0000 0000 0002 ( DtH st dv > > > GET_STATUS ) --- 2 < > > > 0:15.261201 # 11 S Ci 009:00 s 80 06 0600 0000 000a ( DtH st dv > > > GET_DESCRIPTOR [DEVICE_QUALIFIER 0] ) --- 10 < > > > ... > > > 0:15.261981 # 10 C Ci 009:00 --- 0 2 = 0100 > > > 0:15.261982 # 10 S Ci 009:00 s 80 00 0000 0000 0002 ( DtH st dv > > > GET_STATUS ) --- 2 < > > > 0:15.261988 # 11 C Ci 009:00 --- -32 0 > > > > > > I interpret this to mean that the device is asking the host for the > > > device status and then a DEVICE_QUALIFIER descriptor. It returns > > > 0x0100. The device turns around and asks for it again. The host then > > > returns an error, -EPIPE, for that URB. Am I understanding this flow > > > correctly? > > > > Device cannot ask host anything in USB. It just sits there quietly and > > waits to be polled. Always. > > Right. So the host is asking the device for the DEVICE status and > then for the DEVICE_QUALIFIER descriptor. The device sends the status > indicating that it's self-powered. Its response to #11 is what is > broken. It may be getting confused by the second status request *or* > it may have sent the STALL (is that the -32?) before it received the > second GET_STATUS.
It certainly sent the STALL before receiving the second Get-Status, because that Get-Status won't be sent until a response is received for the preceding URB (the Get-Device-Qualifier). Probably the reason for the STALL is that the gadget driver doesn't support Get-Device-Qualifier, implying that it doesn't run at high speed. > > So, in the above exchange, host performs two control transfers. > > The log seems to be post-processed by some tool, which dropped interesting > > information such as URB tag. > > The URB tag is recoded as a number prefixed with #. It makes it > easier to correlate the messages. Do the URB tags have implicit > information in them? Sort of. The tag is the address of the URB, so knowing the tag can tell you which URBs are being reused by the host. Usually you don't care. > The numbers on the left may be manufactured > > from the tag. If so, it appears that the host > > - submits GET_STATUS > > - submits GET_DESCRIPTOR > > - receives status > > - submits another GET_STATUS > > - receives a stall for GET_DESCRIPTOR > > > > So, the control transfers are queued. Are you sure that it's a sane > > thing to do? > > So, where exactly is the STALL in the above exchange? I suspect that > the UDC driver has lost its state and is sending a STALL because it > doesn't know what it is doing. No, the STALL is because the gadget driver told the UDC to stall, because it (the gadget driver) doesn't know how to reply correctly. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
