On Wed, 9 Apr 2014, Clemens Ladisch wrote:
> Alan Stern wrote:
> > The IN transfer was 1 frame long and scheduled for frame 1123, so its
> > completion indicates that the current frame number is >= 1123. The OUT
> > transfer was 6 frames long and scheduled for frame 1111, so it should
> > have completed in frame 1117. But the timestamps show that the two
> > URBs completed at the same time (only 13 us between them).
By the way, the completion times aren't the only thing that look messed
up. The starting frame numbers are also wrong.
Here's an extract showing some of the URB completions for the OUT
endpoint:
> ffff880036e14600 2003747539 C Zo:2:003:1 0:1:1106:0 5 0:0:264
> ffff880036e15c00 2003753507 C Zo:2:003:1 0:1:1111:0 6 0:0:264
> ffff880036e14000 2003758499 C Zo:2:003:1 0:1:1116:0 5 0:0:264
> ffff880036e14600 2003763509 C Zo:2:003:1 0:1:1121:0 5 0:0:264
> ffff880036e15c00 2003768475 C Zo:2:003:1 0:1:1127:0 5 0:0:264
> ffff880036e14000 2003774499 C Zo:2:003:1 0:1:1132:0 6 0:0:264
> ffff880036e14600 2003779478 C Zo:2:003:1 0:1:1137:0 5 0:0:264
Starting frame number---------------------^ ^
Number of frames---------------------------------^
If you do the arithmetic, you'll see that the starting frame numbers
aren't all what they should be. For example, the 2nd URB starts in
frame 1111 and lasts 6 frames, so the 3rd URB should start in frame
1117. But instead it starts in 1116.
These numbers are clear indications of a bug somewhere in the driver.
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
