[Bug 33867] [bisected] Graphics corruption related to pageflip ioctl support in 2.6.38-rc*

[bugzilla-daemon at freedesktop.org]

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

--- Comment #4 from Dave Witbrodt <dawitbro at sbcglobal.net> 2011-02-05 10:58:38 PST ---
Part 2:  pre-rc1 and early rc* kernels suck


In Comment 2 above, I built 4 kernels directly from drm-fixes.  I was guided in
those choices by the results of bisecting the kernel I had made from individual
cherry-picks, believing that the order in which commits appear in 'git log' is
the same as the order used during 'git bisect'.  (That assumption turns out to
have been wrong.)

Anyway, I immediately ran into problems bisecting because the kernels you get
from drm-fixes at specific SHA1 commits are in widely-varying states of
usability.  (That's why I was trying to cherry-pick stuff onto a stable release
of 2.6.37 in the first place!).  Based on my findings with the 4 kernels in
Comment 2, I bisected this way:

    git-bisect  start  1e644d6d  147666fb

There were 5000+ commits between those 2, and the very first commit chosen for
me in between these 2 was something from the post-2.6.37 merge window:  that
kernel would just hang during boot.


SUGGESTION:  this made me wish there was a better way to test new DRM code. 
For example, make it possible to test against kernels where other parts of the
kernel are likely to be in good shape.  Wouldn't it be relatively easy to
either:

    A) have an additional git tree, based on the last stable kernel
       release, with only new DRM-related patches (and no explosive
       merge window or rc* detritus)?

or  B) provide a series of patches so that people wanting to help
       debug this stuff can have kernels that are fairly stable except
       for the new experimental code being tested?

I love git, but this aspect -- using in-flux developer trees for bisecting --
is very bad for user testing.  An "end-user-bisect" tree, rebased at each
stable kernel release, containing only new DRM-related code patches, might be a
great improvement over the current situation.  (Unless having end users running
'git bisect', and spamming the f.d.o. Bugzilla, is something you devs are
intentionally trying to avoid....)

I know this would mean even more burden on already overtaxed devs, but it's
probably something that could be automated if devs who submit patches to D.
Airlie bought into supporting it.  Making a kernel from individual cherry-picks
after gazing at 'git log' changes since the last stable release is much more
difficult, but it's something I've been doing for the past year... I'm just a
noob!  :-)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.