Comment # 33
on bug 99275
from Reimar Imhof
(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.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
