https://bugs.freedesktop.org/show_bug.cgi?id=33867 --- Comment #5 from Dave Witbrodt <dawitbro@xxxxxxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
