https://bugs.freedesktop.org/show_bug.cgi?id=60028
--- Comment #3 from Dave Witbrodt <dawitbro at 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 at 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 at redhat.com> Signed-off-by: Alex Deucher <alexander.deucher at amd.com> The previous commit, which worked fine, was: commit 9af20792124850369e764965690b99b20623dfc4 Author: Daniel Vetter <daniel.vetter at 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 at ffwll.ch> Signed-off-by: Alex Deucher <alexander.deucher at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130129/5145f1b3/attachment-0001.html>