I'm not sure about that last message from usbtest, though. Maybe David can help explain what's going on.
David -- here's the result of one of Charles's tests with my debugging output included (and some other stuff removed).
In short: "Failed with status 0" means that a control transfer was short.
"usbtest" has one message like that which means that the status should have been -EREMOTEIO to indicate the short transfer (since SHORT_NOT_OK is set), but the transfer was reported incorrectly (as if SHORT_NOT_OK was clear).
Remove_list is a list of URBs that were unlinked by the user. Complete_list is a list of URBs that are ready to be sent to
giveback_urb(), either because they completed or because they were
unlinked. The URB's hcd-private data structure (urbp) is freed at the
time the URB is taken off the complete_list.
drivers/usb/misc/usbtest.c: 0000:00:02.2-1:0 TEST 10: queue 4 control calls, 5000 times uhci: added urbp c575653c to complete_list uhci: added urbp c57564f4 to complete_list drivers/usb/host/uhci-hcd.c: uhci_result_control() failed with status 0 uhci: added urbp c57564ac to complete_list uhci: added urbp c5756464 to complete_list 4 URBs completed, one of which was a short transfer.
The first four subtests (#0..#3) will run in a loop, 5000 times each. At most four will be queued simultaneously: 012301230123....0123.
- get device descriptor (18 bytes) - get config descriptor (9 bytes, NOT including interfaces, etc) - get altsetting for interface 0 (one byte, some devices stall this) - get status for interface 0 (two bytes)
There are no short transfers involved.
uhci: took urbp c575653c off complete_list uhci: freed urbp c575653c uhci: took urbp c57564f4 off complete_list uhci: freed urbp c57564f4 uhci: took urbp c57564ac off complete_list uhci: freed urbp c57564ac 3 of them were sent to giveback_urb().
drivers/usb/misc/usbtest.c: subtest 2 error, status -121
So the "get altsetting" subtest neither succeeded (status 0) nor stalled (status -32), but gave a short read (-EREMOTEIO) which is an error.
Is "uhci-hcd" perhaps overwriting -EPIPE? If so, that'd mean other faults are likely being mis-reported.
Another theory would be that the EZ-USB chip is deeply broken, but I thought they were more reasonable than that. (For all that they're only 8 bit CPUs!)
drivers/usb/misc/usbtest.c: control queue 81.0a, err -121, 19997 left
It seems that this output was triggered by the test program without waiting for the 4th URB's completion routine.
And when it prints this, it then unlinks everything that it's queued. Which is at most three urbs, in this case.
uhci: added urbp c575653c to remove_list uhci: added urbp c57564f4 to remove_list Apparently 2 more URBs were submitted and then unlinked.
usb 1-1: hcd_unlink_urb c7118dd8 fail -16 Here's where the test program tried to unlink the 4th URB from above and got an error because it had already completed. Note: c7118dd8 is the URB's address, not the urbp's.
Actually, if it completed two URBs correctly (subtests 0 and 1) then stalled on the next one (subtest 2, as reported) -- then the other URB should still be queued. (Possibly with the first two URBs re-queued after it; after all, they completed fine.)
It's not OK to keep processing a queue after a stall. Drivers need to be able to clean up the queue at that point, since the later requests all depend on that first one having been successfullyp rocessed.
uhci: took urbp c5756464 off complete_list uhci: freed urbp c5756464 Here's where that 4th URB got sent to its completion routine.
... but it never should have been sent to the device, since the driver unlinked it before it should have been able to execute ...
uhci: took urbp c575653c off remove_list uhci: added urbp c575653c to complete_list uhci: took urbp c57564f4 off remove_list uhci: added urbp c57564f4 to complete_list The 2 unlinked URBs were marked as having finished.
uhci: added urbp c5756464 to complete_list Although the same address as that 4th one, this must refer to a new URB that was submitted and completed.
uhci: took urbp c575653c off complete_list uhci: freed urbp c575653c uhci: took urbp c57564f4 off complete_list uhci: freed urbp c57564f4 uhci: took urbp c5756464 off complete_list uhci: freed urbp c5756464 The 2 unlinked URBs and the completed one were sent to giveback_urb().
You've lost me there somewhere. The diagnostics would be easier to read if they referred consistently to urbs, not urbp, since the urbs are what diagnostics in usbcore and device drivers print.
drivers/usb/misc/usbtest.c: subcase 3 completed out of order, last 1
I don't know how the test program is supposed to work. Does this message really reflect what's going on? Does it mean that something isn't working as expected?
Out-of-order is not expected. Didn't you mention a patch that adjusted the unlink order?
But then, subtest 1 shouldn't have been re-executed either, the unlinking was supposed to clean all that up as soon as the stall was detected when processing subtest 2.
- Dave
Alan Stern
------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here: http://www.vmware.com/wl/offer/345/0 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
