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 at 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.
