On Thu, 21 Mar 2013, Soeren Moch wrote:
> > Hi Alan, Soeren
> >
> > Could you word the description a bit better. If Alan did not get it
> > without a bit of thought, few others are going to understand it
> > without a better explanation.
> >
> > Thanks
> > Andrew
> >
>
> Alan,
>
> can you co
On 21.03.2013 22:20, Andrew Lunn wrote:
On Thu, Mar 21, 2013 at 05:12:01PM -0400, Alan Stern wrote:
On Thu, 21 Mar 2013, Alan Stern wrote:
On Thu, 21 Mar 2013, Soeren Moch wrote:
Now I found out what is going on here:
In itd_urb_transaction() we allocate 9 iTDs for each URB with
number_of_p
On 21.03.2013 20:10, Arnd Bergmann wrote:
On Thursday 21 March 2013, Jason Cooper wrote:
On Thu, Mar 21, 2013 at 06:04:59PM +0100, Soeren Moch wrote:
Now I found out what is going on here:
In itd_urb_transaction() we allocate 9 iTDs for each URB with
number_of_packets == 64 in my case. The
On 03/21/13 22:12, Alan Stern wrote:
On Thu, 21 Mar 2013, Alan Stern wrote:
On Thu, 21 Mar 2013, Soeren Moch wrote:
Now I found out what is going on here:
In itd_urb_transaction() we allocate 9 iTDs for each URB with
number_of_packets == 64 in my case. The iTDs are added to
sched->td_list. F
On Thu, Mar 21, 2013 at 05:12:01PM -0400, Alan Stern wrote:
> On Thu, 21 Mar 2013, Alan Stern wrote:
>
> > On Thu, 21 Mar 2013, Soeren Moch wrote:
> >
> > > Now I found out what is going on here:
> > >
> > > In itd_urb_transaction() we allocate 9 iTDs for each URB with
> > > number_of_packets =
On Thu, 21 Mar 2013, Alan Stern wrote:
> On Thu, 21 Mar 2013, Soeren Moch wrote:
>
> > Now I found out what is going on here:
> >
> > In itd_urb_transaction() we allocate 9 iTDs for each URB with
> > number_of_packets == 64 in my case. The iTDs are added to
> > sched->td_list. For a frame-alig
On Thu, 21 Mar 2013, Soeren Moch wrote:
> Now I found out what is going on here:
>
> In itd_urb_transaction() we allocate 9 iTDs for each URB with
> number_of_packets == 64 in my case. The iTDs are added to
> sched->td_list. For a frame-aligned scheduling we need 8 iTDs, the 9th
> one is relea
Hi
On 21/03/13 20:10, Arnd Bergmann wrote:
> On Thursday 21 March 2013, Jason Cooper wrote:
>> On Thu, Mar 21, 2013 at 06:04:59PM +0100, Soeren Moch wrote:
>
>>>
>>> Now I found out what is going on here:
>>>
>>> In itd_urb_transaction() we allocate 9 iTDs for each URB with
>>> number_of_packets
On Thursday 21 March 2013, Jason Cooper wrote:
> On Thu, Mar 21, 2013 at 06:04:59PM +0100, Soeren Moch wrote:
> >
> > Now I found out what is going on here:
> >
> > In itd_urb_transaction() we allocate 9 iTDs for each URB with
> > number_of_packets == 64 in my case. The iTDs are added to
> > sch
On Thu, Mar 21, 2013 at 06:04:59PM +0100, Soeren Moch wrote:
> On 03/17/13 18:36, Alan Stern wrote:
> >On Sun, 17 Mar 2013, Soeren Moch wrote:
> >
> >>For each device only one isochronous endpoint is used (EP IN4, 1x 940
> >>Bytes, Interval 1).
> >>When the ENOMEM error occurs, a huge number of iTD
On 03/17/13 18:36, Alan Stern wrote:
On Sun, 17 Mar 2013, Soeren Moch wrote:
For each device only one isochronous endpoint is used (EP IN4, 1x 940
Bytes, Interval 1).
When the ENOMEM error occurs, a huge number of iTDs is in the free_list
of one stream. This number is much higher than the 2*M e
On Sun, 17 Mar 2013, Alan Stern wrote:
> On Sun, 17 Mar 2013, Soeren Moch wrote:
>
> > For each device only one isochronous endpoint is used (EP IN4, 1x 940
> > Bytes, Interval 1).
> > When the ENOMEM error occurs, a huge number of iTDs is in the free_list
> > of one stream. This number is much
On Sun, 17 Mar 2013, Soeren Moch wrote:
> For each device only one isochronous endpoint is used (EP IN4, 1x 940
> Bytes, Interval 1).
> When the ENOMEM error occurs, a huge number of iTDs is in the free_list
> of one stream. This number is much higher than the 2*M entries, which
> should be the
On 16.03.2013 18:39, Alan Stern wrote:
On Sat, 16 Mar 2013, Soeren Moch wrote:
I implemented the counter. The max value is sampled at the beginning of
end_free_itds(), the current counter value is sampled at the end of this
function. Counter values w/o a max number are from the error path in
it
Ok. I use 2 em2840-based usb sticks (em28xx driver) attached to a
Marvell Kirkwood-SoC with a orion-ehci usb controller. These usb sticks
stream dvb data (digital TV) employing isochronous usb transfers (user
application is vdr).
Starting from linux-3.6 I see
ERROR: 1024 KiB atomic DMA cohere
On Sat, 16 Mar 2013, Soeren Moch wrote:
> I implemented the counter. The max value is sampled at the beginning of
> end_free_itds(), the current counter value is sampled at the end of this
> function. Counter values w/o a max number are from the error path in
> itd_urb_transaction().
> The numb
On 14.03.2013 22:33, Alan Stern wrote:
Maybe a better way to go about this is, instead of printing out every
allocation and deallocation, to keep a running counter. You could have
the driver print out the value of this counter every minute or so. Any
time the device isn't in use, the counter sh
On Fri, 15 Mar 2013, Soeren Moch wrote:
> > The log shows a 1-1 match between allocations and deallocations, except
> > for three excess allocations about 45 lines before the end. I have no
> > idea what's up with those. They may be an artifact arising from where
> > you stopped copying the log
On 14.03.2013 22:33, Alan Stern wrote:
On Thu, 14 Mar 2013, Soeren Moch wrote:
If the memory really is being leaked here in some sort of systematic
way, we may be able to see it in your debugging output after a few
seconds.
OK, here are the first seconds of the log. But the buffer exhaustion
On Thu, 14 Mar 2013, Soeren Moch wrote:
> > If the memory really is being leaked here in some sort of systematic
> > way, we may be able to see it in your debugging output after a few
> > seconds.
> >
>
> OK, here are the first seconds of the log. But the buffer exhaustion
> usually occurs after
On 14.03.2013 21:32, Alan Stern wrote:
On Thu, 14 Mar 2013, Soeren Moch wrote:
I added a debug message to
drivers/usb/host/ehci-sched.c:itd_urb_transaction() to log the
allocation flags, see log below.
But it looks like you didn't add a message to end_free_itds(), so we
don't know when the me
On Thu, 14 Mar 2013, Soeren Moch wrote:
> >> I added a debug message to
> >> drivers/usb/host/ehci-sched.c:itd_urb_transaction() to log the
> >> allocation flags, see log below.
> >
> > But it looks like you didn't add a message to end_free_itds(), so we
> > don't know when the memory gets dealloc
On 14.03.2013 19:48, Soeren Moch wrote:
On 10.03.2013 21:59, Alan Stern wrote:
On Sun, 10 Mar 2013, Soeren Moch wrote:
On Wed, 20 Feb 2013, Soeren Moch wrote:
Ok. I use 2 em2840-based usb sticks (em28xx driver) attached to a
Marvell Kirkwood-SoC with a orion-ehci usb controller. These usb
sti
On 10.03.2013 21:59, Alan Stern wrote:
On Sun, 10 Mar 2013, Soeren Moch wrote:
On Wed, 20 Feb 2013, Soeren Moch wrote:
Ok. I use 2 em2840-based usb sticks (em28xx driver) attached to a
Marvell Kirkwood-SoC with a orion-ehci usb controller. These usb sticks
stream dvb data (digital TV) employin
On Sun, 10 Mar 2013, Soeren Moch wrote:
> > On Wed, 20 Feb 2013, Soeren Moch wrote:
> >
> >> Ok. I use 2 em2840-based usb sticks (em28xx driver) attached to a
> >> Marvell Kirkwood-SoC with a orion-ehci usb controller. These usb sticks
> >> stream dvb data (digital TV) employing isochronous usb tr
On 21.02.2013 19:54, Alan Stern wrote:
I trust you won't mind if I put this on the public mailing list. In
general, problems of this sort should be discussed in public. In
addition to creating a permanent record in the various mailing list
archives, it also gives other people a chance to learn
I trust you won't mind if I put this on the public mailing list. In
general, problems of this sort should be discussed in public. In
addition to creating a permanent record in the various mailing list
archives, it also gives other people a chance to learn about these
problems and to chime in if t
On Wed, Jan 30, 2013 at 04:35:02PM -0500, Alan Stern wrote:
> This patch (as1653) fixes a bug in ehci-hcd. Unlike iTD entries, an
> siTD entry in the periodic schedule may not complete until the frame
> after the one it belongs to. Consequently, when scanning the periodic
> schedule it is necessa
This patch (as1653) fixes a bug in ehci-hcd. Unlike iTD entries, an
siTD entry in the periodic schedule may not complete until the frame
after the one it belongs to. Consequently, when scanning the periodic
schedule it is necessary to start with the frame _preceding_ the one
where the previous sc
29 matches
Mail list logo
