On Tue, 31 Aug 2004, Laurent Pinchart wrote: > > And why is the link field equal to 1? That shouldn't happen... > > The least significant bit in the link field is used to indicate termination of > the linked list. This seems to be normal.
Actually it isn't. The last entry in the linked list is a special "dummy" entry, used as a workaround for a bug in Intel's controllers. The QH for a regular low-speed control message would never be the last in the linked list; it would be followed by the skeleton QH for full-speed control messages, the one for full-speed bulk messages, and the dummy entry. But none of this is relevant to your problem. > When reading the configuration descriptors, the USB stack sends a > GET_DESCRIPTOR request, with a small buffer size, and allocate a big enough > buffer using the length supplied in the response to the first request. The > GET_DESCRIPTOR request is then replayed using the big buffer. > > Here's a sample for 2.4.27: > > SETUP: 80 06 00 02 00 00 08 00 > SETUP: 80 06 00 01 00 00 19 00 > > The initial buffer is 8 (hardcoded in the kernel) bytes long, the complete > buffer is 25 (0x19) bytes long. > > Here's the same sample from 2.6.7: > > SETUP: 80 06 00 02 00 00 09 00 > SETUP: 80 06 00 01 00 00 19 00 > > Here, the initial buffer is 9 bytes long (the kernel uses the constant value > USB_DT_CONFIG_SIZE), the complete buffer is 25 (0x19) bytes long. That change (from 8 to 9 bytes) was made fairly recently. > Note that both requests, and further GET_DESCRIPTOR requests, are processed > correctly by the device which returns the requested descriptors, identical > under both kernels. > > As that was the only difference remaining between the 2.4.27 and 2.6.7 logs, I > decided to give it a try, and I modified the 2.6.7 kernel to use a fixed size > of 8 bytes instead of 9 bytes for the initial GET_DESCRIPTOR request in > [EMAIL PROTECTED] > > The device detection and initialization kept working (there was no reason for > it to break), and, to my surprise, the Stall condition disappeared. > > I tried several other values (6, 7, 10, 11, 12) for the initial buffer size. > All of them gave valid results when reading the descriptors, but all of them > resulted in a Stall condition later when sending the vendor command. > > I suspect a broken device, but I'm really puzzled. There's no question your device doesn't work right. Or at least, the vendor-specific part doesn't. On the other hand, who knows? Maybe the vendor designed it that way on purpose... > Unfortunately, my problems are not over, as the device stops responding and > times out after the first vendor specific request, so I'm up for more > investigation. > > Anyway, could anyone comment on the problem I discovered ? Could it be a > UHCI/root hub problem ? Or is it certain that the device is faulty ? If the > device is faulty, what should be done ? Could the buffer size be lowered from > 9 to 8, or is it against the kernel policies to make such a change for a > broken device ? It's certainly not the kernel's fault. And the buffer size cannot be lowered back to 8, as raising it to 9 was necessary to work with other (slightly broken) devices. Another possibility is to increase the buffer to 64 bytes. That's what Windows uses for full-speed devices, although I don't know how it handles low-speed devices. Of course, even if the buffer size is changed it won't help you very much, because your device will still fail to respond properly to the vendor-specific requests. On the whole, it seems better to fix the device than to change the kernel. > If the device is broken, I'll contact the vendor to get a firmware update, or > a refund. I'd be glad if someone could point me to relevant part of the USB > specification, as I'm not too familiar with them and might easily have > skipped an important point. > > Thanks in advance for all the help you can provide. > > Laurent Pinchart I don't think there's any part of the specification that says "The device shall not crash"! Also bear in mind that when implementing vendor-specific commands, the vendor is allowed carte-blanche. If necessary, you should simply point out that both 8- and 9-byte requests are perfectly legal and the device should be able to work with either one. Alan Stern ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
