On 02/03/2013 11:08 AM, Alan Stern wrote:
In $SUBJECT you say that the problem is associated with bulk transfers.
Those are listed in the "async" file, which you did not report. Was
the file empty?
I apologise. Yes the async files where empty.
I am not certain what it is worth, but I have managed to capture
usbmon/1u on a system which lost access to the ports, though it is quite
sizable. Right about 3MB/min of data.
Here is the last few transactions before the device "appears" to hang,
and before attempting kill -9 the controlling application.
dd4b54c0 3248782520 S Bi:1:003:3 -115 512 <
dd4b57c0 3248782543 C Bi:1:003:1 0 2 = 3160
dd4b57c0 3248782554 S Bi:1:003:1 -115 512 <
dd4b5440 3248783508 C Bi:1:003:3 0 2 = 3160
dd4b5440 3248783522 S Bi:1:003:3 -115 512 <
dd4b5740 3248783547 C Bi:1:003:1 0 2 = 3160
dd4b5740 3248783559 S Bi:1:003:1 -115 512 <
dd4b54c0 3248784506 C Bi:1:003:3 0 2 = 3160
dd4b54c0 3248784519 S Bi:1:003:3 -115 512 <
dd4b57c0 3248784542 C Bi:1:003:1 0 2 = 3160
dd4b57c0 3248784554 S Bi:1:003:1 -115 512 <
dd4b5440 3248785513 C Bi:1:003:3 0 2 = 3160
dd4b5740 3248785556 C Bi:1:003:1 0 2 = 3160
dd4b5740 3248785568 S Bi:1:003:1 -115 512 <
dd4b5740 3248868626 C Bi:1:003:1 0 2 = 3160
dd4b57c0 3248869618 C Bi:1:003:1 0 2 = 3160
The transaction at 3248785513 is the last from 1:003:3 (BulkIn?). The
other endpoints on 1:003 continue to operate normally, and we have
validated that we can still transmit data out through the device, we can
simply no longer receive.
--
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