On Tue, 18 May 2010, Stephen Warren wrote: > > The usbmon traces show that the device sometimes dies when it receives > > a Get-Device-Qualifier request. Not always, but sometimes. > > I took a look at the USB specification. Is the failing command the > following (from a good run): > > e8148c80 619776204 S Ci:5:004:0 s 80 06 0600 0000 000a 10 < > e8148c80 619780175 C Ci:5:004:0 -71 0 Yes. Except that this excerpt is from a bad run, not a good one. > If I understand it, the -71 is the result code, and -71 indicates that > it fails (specifically -EPROTO if I'm reading the kernel sources > correctly). In a bad run, I see: > > e5b6ae80 280483165 S Ci:5:002:0 s 80 06 0600 0000 000a 10 < > e5b6ae80 280485150 C Ci:5:002:0 -32 0 And this was from a good run. > ... with result code -32, which is also a failure (specifically -EPIPE). > > Am I interpreting this all correctly? Is this command expected to fail > in a specific way even in a "good" case? If a device doesn't support dual-speed operation (e.g., it can run only at full speed) then it is supposed to respond with a STALL to this request. -EPIPE is the error code corresponding to STALL, so getting a -EPIPE status is normal and expected. -71 (-EPROTO) is never supposed to happen. It means that the device didn't respond at all -- the USB cable was unplugged, or the firmware crashed, or something else similarly went drastically wrong. > Thanks for any pointers. See Documentation/usb/error-codes.txt. > > I have no idea why it would do this. A firmware bug would generally > > cause it to die every time, but there's no other obvious explanation. > > Particularly since the alternate firmware does not die; it handles the > > request correctly. > > Hmmm. I guess I'll go read the PIC USB interface specification and see > how much of this is SW vs. HW controlled on this microcontroller. It's odd that this occurs only some of the time. Maybe it depends on some low-level timing details. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
