Comment # 3
on bug 60028
from Dave Witbrodt
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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
