On 04/16/2014 01:17 PM, Russel Hughes wrote:
On 9 April 2014 19:53, Alan Stern wrote:
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
tra
On 9 April 2014 19:53, Alan Stern wrote:
> 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 s
On Thu, 10 Apr 2014, David Laight wrote:
> You also definitely don't want to cancel an isoc urb.
> Doing so is likely to corrupt the kernel heap.
>
> If an isoc urb generates multiple TRB the code allocates a little
> structure 'per TRB' and links it to the urb.
> This seems to be done so that it
From: Alan Stern
...
> Furthermore, I clearly recall Sarah Sharp (the original maintainer for
> xhci-hcd) saying that the support for isochronous transfers needed
> attention. This may well be an example.
You also definitely don't want to cancel an isoc urb.
Doing so is likely to corrupt the kern
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 , so it should
> > have co
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 , so it should
> > have co
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 , so it should
> have completed in frame 1117. But the timestamps show that t
On Tue, 8 Apr 2014, Russel Hughes wrote:
> Hi,
>
> I put in a new kernel and get the response from uname -r of
> 3.14.0-031400-generic, apologies for the pedantry I am not that sure
> what I am doing. The device behaves exactly the same as default Linux
> kernel, buffer is erratic not stable like
