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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Feb 5 11:02:57 PST 2011


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

--- Comment #5 from Dave Witbrodt <dawitbro at sbcglobal.net> 2011-02-05 11:02:57 PST ---
Created an attachment (id=42968)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=42968)
Output of 'git bisect log' with drm-airlied/drm-fixes tree

Part 3:  My useless bisect of drm-fixes


I started over, after having had my butt kicked by that evil merge-window
kernel.  This time I ran:

    git-bisect  start  1e644d6d  147666fb  drivers/gpu/drm/radeon

This posed the potential issue that the commit I was trying to find was not
something that touched file(s) in d/g/d/radeon.  If that was the result I was
going to bisect again without specifying a directory, but it actually turned
out fine.  The bisect log is attached.

When I originally viewed 'git log' to select cherry picks, I saw an ordering
like this:

[NEWEST]
...
1e644d6d  drm/radeon/kms: re-emit full context state for evergreen blits
...
147666fb  drm/radeon: Use the ttm execbuf utilities
...
6f34be50  drm/radeon/kms: add pageflip ioctl support (v3)
f5a80209  drm/kms/radeon: Add support for precise vblank timestamping.
...
[OLDEST]

I applied the individual cherry-picks in order from old to new, assuming later
patches would depend on earlier ones to avoid conflicts.  In Comment 2 above,
kernel 3 (147666fb) was OK and kernel 4 (1e644d6d) caused the black
fades/melts.

The 'git bisect' process then surprised me:  in spite of the order the commits
appear in 'git log', the bisection found f5a80209 and 6f34be50 _between_
147666fb and 1e644d6d !  This explains why I was baffled in Comment 2 above: 
147666fb was "good" because it is actually before f5a80209 (the last commit
before problems begin) in the git history.

These results correspond exactly to what I had found in my original
(preliminary) report here.

This seems to point firmly at one commit:

    6f34be50  drm/radeon/kms: add pageflip ioctl support (v3)

However, I have many doubts.  Looking at the list of commits I originally used
(see my first attachment here) there are two complex series involved:

6f34be50  drm/radeon/kms: add pageflip ioctl support (v3)
3e4ea742  drm/kms/radeon: Reorder vblank and pageflip interrupt handling.
b6724405  drm/kms/radeon: Use high precision timestamps for pageflip 
                          completion events.

    and

d6ea8886  drm/ttm: Add a bo list reserve fastpath (v2)
ecf7ace9  kref: Add a kref_sub function
2357cbe5  drm/ttm: Use kref_sub instead of repeatedly calling kref_put
68c4fa31  drm/ttm: Optimize ttm_eu_backoff_reservation
96726fe5  drm/ttm: Don't deadlock on recursive multi-bo reservations
702adba2  drm/ttm/radeon/nouveau: Kill the bo lock in favour of a bo device
          fence_lock
95762c2b  drm/ttm: Improved fencing of buffer object lists
65705962  drm/ttm/vmwgfx: Have TTM manage the validation sequence.
eba67093  drm/ttm: Fix up io_mem_reserve / io_mem_free calling

Therefore, I think this bisection was inconclusive:  kernels built from commits
where the "pageflip" series is incomplete or the "TTM" series is incomplete
cause hangs; but what I am _really_ looking for is the first commit that allows
me to build a non-hanging kernel and which also exhibits the graphics
corruption.  (Here, by "hangs" I mean that 'prboom-plus' becomes unresponsive
instead of performing the all-black fade/melt routine, and I have to use 'kill
-9' via SSH.)

For the bisection to succeed, maybe I would have to treat kernels with hangs as
"good" (as well as those causing no glitches at all) and only treating
_working_ kernels which cause black fades as "bad".

In any event, I suspect now that all of this bisecting after the first one I
did (on the 2.6.37 + cherry-picks local branch) has been for nothing.  [See
next comment.]

It is still possible that the hangs I saw during bisection might have some
relevance for bug #33515 and bug #33418, but I think it is more likely that
those were merely artifacts of 'git bisect' landing in the middle of incomplete
patch series (the "pageflip" and "TTM" series I listed above).

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


More information about the dri-devel mailing list