https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #33 from Reimar Imhof tuxuser@quantentunnel.de --- (In reply to Michel Dänzer from comment #27)
(In reply to Reimar Imhof from comment #26)
Together with comment #24 there is a render bug in kernel 4.8 that shows up at 100% cpu load. With kernel 4.9 this same bug shows up at 0% / idle cpu load.
With af79ad2b1f337a00aa150b993635b10bc68dc842 Merge branch 'sched-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip it changed from "bug shows at 100% load" to "bug shows at 0% load". And the change is something about the scheduler. To me this seems likely.
Not really. That commit is a pure merge commit, which makes it unlikely that it behaves any differently from either of its parent commits. So git bisect should have identified one of its ancestor commits instead. The fact that it identified a pure merge commit indicates that the result is incorrect, most likely because at least one commit along the way was incorrectly classified as good (or bad).
I forgot to mention: I had a look at the first merge commits. I did _not_ do a "git bisect" but for example a "git reset --hard 7af8a0f8088831428051976cb06cc1e450f8bab5" followed by a "make rpm" to compile "Merge tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux". "e606d81d2d9596ab2b4fd0dc052eea0485b7e8c2 Merge branch 'ras-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" was a good commit - no problems at idle cpu as described in Comment #23. That one was followed by "af79ad2b1f337a00aa150b993635b10bc68dc842 Merge branch 'sched-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip" which turned out to be the first bad commit (glitches at 0 cpu load). So all tested commits were pure merge commits.