Re: Continuous stream of small bulk transfers hangs on OHCI-based systems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux