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@amd.com 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.