[Bug 60028] Post-3.7.x memory leak, Radeon Evergreen, bisected

[bugzilla-daemon@freedesktop.org]

[-- Attachment #1.1: Type: text/plain, Size: 3410 bytes --]

https://bugs.freedesktop.org/show_bug.cgi?id=60028

--- Comment #3 from Dave Witbrodt <dawitbro@sbcglobal.net> ---
Bisecting

So far, I have only bisected using my local custom kernel branch.  As described
above, I use stable kernel releases to avoid the massive breakage that
frequently occurs in -rc kernels, and I cherry pick commits from drm-fixes and
drm-next.  This is a potential source of error (on my part), so I will not be
offended if anyone objects to me reporting bugs against such kernels.  My
justification is that the HEAD of drm-fixes, which is

    3.8.0~rc3 at commit 48367432 of Jan. 26

also leaks memory if I build it and use it on my system.  I bisected using my
custom branch first only to save time:  I add cherry picks in bunches, and keep
separate list files of which commits I have used, so manually bisecting using
those files rapidly led me to the first commit which caused the kernel to leak
memory.

[I will bisect using drm-fixes (or drm-next) if asked, but there are issues
with Mesa not being compatible before a certain point in mid-December, so that
I would have to use an older version of Mesa or patch some of the older
bisection points with later commits in order to use the version of Mesa
I currently have installed.]

For this testing, I started with stable kernel 3.7.4 and applied my lists of
cherry picks that had built up since 3.7-rc7 or so.  I had built up 11 lists of
commits as I added new upstream code to my local branch, so I could perform a
manual bisection by applying an entire list at a time until I found a kernel
which leaked memory.  From that, I would know which list introduce the problem,
and I could build kernels at each commit in that list until I found the first
one that resulted in leaks.  (If anyone is interested in those lists I will be
glad to post them; I have only withheld them for the sake of brevity.)

The manual bisection led me to a last good commit and a first bad commit.  The
cherry picking process causes my branch to have new SHA1 ID numbers, so I
instead of using the 'git log' info from my branch am will use the info
from the drm-airlied/drm-fixes branch.  The first bad commit was:

    commit 4ac0533abaec2b83a7f2c675010eedd55664bc26
    Author: Jerome Glisse <jglisse@redhat.com>
    Date:   Thu Dec 13 12:08:11 2012 -0500

        drm/radeon: fix htile buffer size computation for command stream
checker

        Fix the size computation of the htile buffer.

        Signed-off-by: Jerome Glisse <jglisse@redhat.com>
        Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


The previous commit, which worked fine, was:

    commit 9af20792124850369e764965690b99b20623dfc4
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Tue Dec 11 23:42:24 2012 +0100

        drm/radeon: fix fence locking in the pageflip callback

        We need to hold bdev->fence_lock while grabbing a reference to
        the fence, to prevent concurrent clearing/changing of the
        ttm_bo->sync_obj field.

        Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
        Signed-off-by: Alex Deucher <alexander.deucher@amd.com>


This was a time-consuming process, but much shorter than it would have been
using 'git bisect' in drm-fixes.  Later, I made two attempts to revert the
"bad" code on top of the HEAD of my local branch.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[-- Attachment #1.2: Type: text/html, Size: 4551 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel