Hi Alan and everybody, Sorry for my late reply. I don't have much time to spend investigating this USB problem, but I definitely got somewhere.
> > [c65950c0] link (00000001) element (065841e4) > > Depth traverse > > Maybe that line is relevant. It's not present under 2.6; do you know why > it's there under 2.4? 2.4 sets the control message to use Depth traversal for low speed devices and Breadth traversal for full speed devices. 2.6 sets Breadth traversal for all control messages. I have no idea why the behaviour changed, but it doesn't seem to affect the device under test. > 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. > If you come up with an explanation, I'd really like to hear it. Well, here is the explanation. Please sit down before reading further down :-) 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. 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. 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 ? 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
pgpmaV95uMt2U.pgp
Description: signature
