scuss this problem on the usb mailing list.
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
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 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 kno
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 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 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 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/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_l
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
11 matches
Mail list logo
