<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Post-3.7.x memory leak, Radeon Evergreen, bisected" href="https://bugs.freedesktop.org/show_bug.cgi?id=60028#c3">Comment # 3</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Post-3.7.x memory leak, Radeon Evergreen, bisected" href="https://bugs.freedesktop.org/show_bug.cgi?id=60028">bug 60028</a> from <a class="email" href="mailto:dawitbro@sbcglobal.net" title="Dave Witbrodt <dawitbro@sbcglobal.net>"> Dave Witbrodt</a> <pre>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 <<a href="mailto:jglisse@redhat.com">jglisse@redhat.com</a>> 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 <<a href="mailto:jglisse@redhat.com">jglisse@redhat.com</a>> Signed-off-by: Alex Deucher <<a href="mailto:alexander.deucher@amd.com">alexander.deucher@amd.com</a>> The previous commit, which worked fine, was: commit 9af20792124850369e764965690b99b20623dfc4 Author: Daniel Vetter <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>> 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 <<a href="mailto:daniel.vetter@ffwll.ch">daniel.vetter@ffwll.ch</a>> Signed-off-by: Alex Deucher <<a href="mailto:alexander.deucher@amd.com">alexander.deucher@amd.com</a>> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>