On Thu, 13 May 2010, Tvrtko Ursulin wrote:
You could just enable CONFIG_DEBUG_KMEMLEAK on 2.6.33, mount the debugfs
and do a 'cat /sys/kernel/debug/kmemleak' after a half-hour or so.
I could do it if radeon/drm guys would be interested in those results? (Given
how 2.6.34-rc7 is not
On Wednesday 26 May 2010 10:21:36 David Rientjes wrote:
On Thu, 13 May 2010, Tvrtko Ursulin wrote:
You could just enable CONFIG_DEBUG_KMEMLEAK on 2.6.33, mount the
debugfs and do a 'cat /sys/kernel/debug/kmemleak' after a half-hour or
so.
I could do it if radeon/drm guys would be
[Snipped localdomain guy from Cc]
On Wednesday 12 May 2010 14:29:16 Jerome Glisse wrote:
On Wed, May 12, 2010 at 11:50:41AM +0100, Tvrtko Ursulin wrote:
On Wednesday 12 May 2010 11:38:05 Tvrtko Ursulin wrote:
[snip]
I think it is DRM (radeon) related, leak stopped when I closed all X
On Thursday 13 May 2010 13:29:49 Catalin Marinas wrote:
Tvrtko Ursulin tvrtko.ursu...@sophos.com wrote:
On Wednesday 12 May 2010 14:00:51 Pekka Enberg wrote:
[snip]
You might want to try out the built-in kernel memory leak detector.
See Documentation/kmemleak.txt for details how to
On Wednesday 12 May 2010 11:21:48 Tvrtko Ursulin wrote:
Hi all,
As the subject says, is this a know issue? I have been tracking the growth
at one second intervals and it looks like this:
512 (67716608) Slab: 606744 kB
512 (67717120) Slab: 606752 kB
512 (67717632)
On Wednesday 12 May 2010 11:38:05 Tvrtko Ursulin wrote:
[snip]
I think it is DRM (radeon) related, leak stopped when I closed all X
programs. I am compiling 2.6.33.3 right now and will soon reboot into it.
Leak is still present in 2.6.33.3 - the more GUI activity the more it leaks.
So the
On Wed, May 12, 2010 at 11:50:41AM +0100, Tvrtko Ursulin wrote:
On Wednesday 12 May 2010 11:38:05 Tvrtko Ursulin wrote:
[snip]
I think it is DRM (radeon) related, leak stopped when I closed all X
programs. I am compiling 2.6.33.3 right now and will soon reboot into it.
Leak is still
