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
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 come up with a better
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
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.
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
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
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
> >
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
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
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
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 iTDs is in the
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
sched-td_list.
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 == 64 in my case.
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 released
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-aligned
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 == 64 in my case.
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.
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 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
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
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
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
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
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 there
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 higher
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
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 number
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
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 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 data.
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
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
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
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
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
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
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)
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)
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
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 deallocated. And you
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
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 several
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
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
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
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
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 transfers
50 matches
Mail list logo
