Sorry, I meant to post this analysis earlier in the week but got distracted...
On Sat, 13 Jan 2007, David Brownell wrote: > > # ./testusb -D /proc/bus/usb/004/010 -t10 > > (Never completes, no output) > > dmesg: > > > > Jan 8 12:37:38 egypt kernel: usbtest 4-4:3.0: TEST 10: queue 32 > > control calls, 1000 times > > (no further output) > > Actually if you unplug the device at that point you should get a short > burst of additional diagnostic output, saying among other useful data > just which subtest failed. > > Also, unless this is with UHCI, enabling USB debugging will produce > files /sys/class/usb_host/usb_hostN/async showing the schedule of USB > transactions. What you could do is snapshot that file when this hang > happens ... the top few entries for the endpoint for this test will be > informative, showing exactly which subtest saw trouble. > > (In the case of test #1, the actual failure would likely have been > triggered by the preceding request, or maybe the one before that...) > > > I'm not sure what to make of this usbmon stuff. All the urbs are > submitted into a queue, so that the responses look like they're > out of order. What's needed is a bit of postprocessing to associate > the responses with the requests. Your interpretation of the results was a little bit off. Things make more sense if you ignore the submissions and pay attention only to the completions. It's not hard to match the pattern of responses with the sequence of subtests. > > c7848500 33910869 S Ci:024:00 s 80 06 0400 0000 0009 9 < > > c7848260 33911110 C Co:024:00 0 0 > > subtest #7 (by inference; should have stalled). I don't see > a response for c7848500, or a request for c7848260. The submission is for subtest #7, but more importantly, the completion was for a prior subtest #8 (clear endpoint stall). > > c7848260 33911112 S Co:024:00 s 02 01 0000 0000 0000 0 > > c7848380 33911117 C Ci:024:00 0 2 = 0000 > > subtest #8 (by inference; should have stalled) Completion was for subtest #9 (get endpoint status); it returned 2 bytes as expected. > > c7848380 33911118 S Ci:024:00 s 82 00 0000 0000 0002 2 < > > c7848560 33911124 C Ci:024:00 -121 39 = 09022700 010304c0 01090400 > > 0003ff00 0005 > > 0705 87020002 00070503 02000201 > > subtest #9 (by inference, the next one being #10) Completion was for subtest #10 (get config descriptor, short read). > > c7848560 33911125 S Ci:024:00 s 80 06 0200 0000 0400 1024 < > > c78481a0 33911235 C Ci:024:00 -32 0 > > This "S" was obviously subtest #10, but the STALL response coming > back for c78481a0 doesn't match any URB submitted in the subset > of this log you included. The stall was for subtest #11 (get endpoint descriptor -- always stalls). > It's clear that after that STALL was issued, something got > confused in terms of handling the next request ... what ever > it was. This is not uncommon ... fault paths are trouble, > and test #10 makes a point of triggering them. It even makes > a point of triggering several fault paths in a row, so that > bugs in cleanup of one are able to trigger additional bugs > when processing later ones. :) The next response should have been for subtest #12 (get string 0 descriptor). Obviously that's where the trouble lies. > > SETUP 80.06 v0300 i0000 9 > > Which is a GET_DESCRIPTOR request for string zero As I said. > > In one failing case the lines were output 1312 times, in another case > > 1495 times, then no further output. In another case they were output > > only once. When the test passes they are output 2000 times. Normally > > the last line to be output is the 80.06 line, but I have seen a case > > where it was the other one. Confirming that this is where the failure occurs. Alan Stern ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
