On Thu, 17 Jul 2003, David Brownell wrote: > Alan Stern wrote: > > > 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.
Maybe there aren't supposed to be. But there's no question in my mind that subtest 2 completed as a short transfer. Part of the log that I omitted includes the TD status word for that URB; it has the Active bit off, the Short-Packet-Detect bit on, and the Stalled bit off. It also shows a MaxLen of 1 and an Actual-Length of 0. > > 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. Just as I said. > Is "uhci-hcd" perhaps overwriting -EPIPE? If so, that'd mean > other faults are likely being mis-reported. No, it's not. > 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!) Remember, Charles said that he was going through all this to test his firmware. Isn't it possible that an error in his firmware program could have caused this short transfer? (Although, come to think of it, this test was supposedly run without any firmware loaded...) > > 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. As we see immediately below... > > 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. But assuming it didn't stall, this is just what you would expect. The URBs for subtests 0 and 1 in the next loop were unlinked, and the program tried to unlink the URB for subtest 3 but failed since that URB had already completed. There's nothing wrong with completing a queued URB that follows one with a short transfer. > > 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. Does this refer to subtest 3 in the second loop? It's an URB that was submitted after all those earlier ones were unlinked, and apparently it completed normally. If it were subtest 2, I would have expected it to result in another short transfer. > > 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. Sorry about that; I didn't think it would make much difference. These three URBs are the unlinked second-loop instances of subtests 0, 1, and possibly 3. I don't know why there doesn't seem to be any subtest 2 in the second loop. > > 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? Yes, that was included in this test. In prior tests the log shows URBs being sent to giveback_urb() opposite to the order in which they were unlinked. That didn't happen here. > 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. Maybe the test program included some assumption similar to the one you made (that subtest 2 should have completed normally or stalled), which caused it to think that something was out of order when in fact it wasn't. 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
