Kai Wasserbäch wrote:
Kai Wasserbäch wrote on 15.11.2014 22:22:
Kai Wasserbäch wrote on 15.11.2014 16:33:
Is there anything besides a bisect you would need to debug this?
Ok, I did a bisection, but that time was wasted for sure. My "first
bad commit" isn't bad at all. Is there any way to improve that
experience? I'm really loathe to go through the dozen boots again,
just to get another broken bisection.
Ok, after looking at the changes for radeon I decided to try the HEAD
of drm-next-3.19 (c81b99423bd9d3fc35ac8752ca5fb4c50eab063c). That was
still good. Armed with this much smaller bisection range, I came up
with a result that sounds at least believable:
3cd76f3901e73a4a61d78c4526dcbf6d87c9a928 is the first bad commit
commit 3cd76f3901e73a4a61d78c4526dcbf6d87c9a928 Author: Christian
König <christian.koenig@xxxxxxx> Date: Mon Oct 13 12:41:47 2014
+0200
drm/radeon: update the VM after setting BO address (v2)
Yes, that seems to be it for me also - but just to confuse things I've
been running with that for several weeks without incident, so something
brought in from the recent merges/a new patch doesn't play nicely with it.
If you wanted to test you could get back to how drm-next-3.19-wip was
last week by
git reset --hard 3.18.0-rc2-gc76c717
and you can see it's there with git log about 6/7 commits down.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
