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
-- Forwarded message --
From: Russel Hughes
Date: 6 April 2014 11:32
Subject: Isochronos audio
To: linux-usb
>
> Can you describe the actual problem ? How can you trigger it ? What are
> you doing when the problem arises ? Do you hear audio glitches or does
>
>
> Can you describe the actual problem ? How can you trigger it ? What are
> you doing when the problem arises ? Do you hear audio glitches or does
> the device disconnect ? Do you have a crash ? Does the *same* device
> work on other setups ?
>
> Try to capture a usbmon trace of the failure, that
10 matches
Mail list logo
