(In reply to Alex Deucher from comment #264)
> (In reply to Kajzer from comment #263)
> > git bisect visualize=20
> > commit 6101b3ae94b4f266456308824e9ca4eab1235d1a
> > Author: Alex Deucher <alexander.deucher@amd.com>
> > Date:   Tue Aug 19 11:54:15 2014 -0400
> >=20
> >     drm/radeon: fix active cu count for SI and CIK
> >=20=20=20=20=20
> >     This fixes the CU count reported to userspace for
> >     OpenCL.
> >=20=20=20=20=20
> >     bug:
> >     https://bugzilla.kernel.org/show_bug.cgi?id=3D82581
> >=20=20=20=20=20
> >     Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
> >     Reviewed-by: Michel D=C3=A4nzer <michel.daenzer@amd.com>
> >     Cc: stable@=
vger.kernel.org
>=20
> Something must have gone wrong in your bisect.  That commit does not a=
ffect
> your chip.  Perhaps the bug is somewhat hard to reproduce which caused=
 you
> to mis-mark some commits as good.

Could be the case. Bug is hard to reproduce because it happens only in games
and at random intervals. And you can't idle it. Sadly I don't have much time
for gaming now. I'll try it one more time, more thoroughly.
One question though, if I'm 100% positive that v3.16 is good, should I skip
bisects (mark them as good) if they end up as 3.16.0+ image after bisect ?
Thus testing only v3.17 bisects.
Because out of 7 steps 3 were from 3.17, it can save a lot of time if I cou=
ld
skip 3.16 bisects.