On Mon, 22 May 2017, Marek Pikarski wrote: > Hi! > > I am currently hunting the source of an issue that we have with an USB > modem. There could even be some HW / board design issue. > > My idea was to try the kernel USB unit tests and this seems to work out > as it gave me some interesting results! > > It would be so great if someone on this list had an idea what the test > results mean and whether these results are pointing to a certain problem... > > Here the interesting part (TEST 10 is the one always failing) of the > testusb output: > > # ./testusb -l -D /dev/bus/usb/001/003 -t 10 > unknown speed /dev/bus/usb/001/003 0 > /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe) > /dev/bus/usb/001/003 test 10, 8.011131 secs > /dev/bus/usb/001/003 test 10, 8.010904 secs > /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe) > /dev/bus/usb/001/003 test 10 --> 121 (Remote I/O error) > /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe) > /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe) > /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe) > /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe) > /dev/bus/usb/001/003 test 10, 8.012122 secs > /dev/bus/usb/001/003 test 10 --> 32 (Broken pipe) > ... Test 10 tests how well control messages are handled when they are queued up. It has a large number of subcases that get tried iteratively, and the whole thing is repeated, in this case 1000 times. > And here the corresponding info from the usbtest kernel module (dmesg > output): > > [15298.990000] usbtest 1-2:3.0: TEST 10: queue 32 control calls, 1000 times > [15300.330000] usbtest 1-2:3.0: subtest 4 error, status -32 > [15300.330000] usbtest 1-2:3.0: control queue 80.00, err -32, 26667 > left, subcase 4, len 0/2 Subtest 4 is a Get-Device-Status control request. It is not expected to fail. The log indicates that the device sent a STALL instead of a proper reply -- that's what the -32 means. However, the subtest did complete correctly over a hundred times before the failure occurred. > [15300.350000] usbtest 1-2:3.0: subcase 5 completed out of order, last 3 This means subtest 3 was the one that completed previously. This should not happen -- requests are always supposed to complete in order, so subtest 4 should have completed before 5. > [15300.350000] usbtest 1-2:3.0: subcase 4 completed out of order, last 4 That's even weirder. I don't see how that could happen. But the error pathways in this driver have not been tested thoroughly. > [15300.370000] usbtest 1-2:3.0: TEST 10: queue 32 control calls, 1000 times > [15308.380000] usbtest 1-2:3.0: TEST 10: queue 32 control calls, 1000 times > [15316.390000] usbtest 1-2:3.0: TEST 10: queue 32 control calls, 1000 times > [15322.230000] usbtest 1-2:3.0: subtest 4 error, status -32 > [15322.230000] usbtest 1-2:3.0: control queue 80.00, err -32, 8715 left, > subcase 4, len 0/2 > [15322.240000] usbtest 1-2:3.0: subcase 5 completed out of order, last 3 > [15322.250000] usbtest 1-2:3.0: subcase 4 completed out of order, last 4 > [15322.260000] usbtest 1-2:3.0: TEST 10: queue 32 control calls, 1000 times > [15324.870000] usbtest 1-2:3.0: subtest 9 error, status -121 > [15324.870000] usbtest 1-2:3.0: control queue 82.00, err -121, 21574 > left, subcase 9, len 0/2 Error code -121 means a short reply was received -- in this case 0 bytes instead of 2. The rest of the errors are all similar to these. > Looking forward to hear from you! Best regards, Marek Bear in mind that the problem could lie in the test computer rather than in the device! Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
