Commen=
t # 33
on bug 99275<=
/a>
from Reimar Imhof
(In reply to Michel D=C3=A4nzer 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.
> >=20
> > With=20
> > 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 s=
hows at 0% load". And the
> > change is something about the scheduler.
> > To me this seems likely.
>=20
> Not really. That commit is a pure merge commit, which makes it unlikel=
y that
> it behaves any differently from either of its parent commits. So git b=
isect
> should have identified one of its ancestor commits instead. The fact t=
hat it
> identified a pure merge commit indicates that the result is incorrect,=
most
> likely because at least one commit along the way was incorrectly class=
ified
> as good (or bad).
I forgot to mention:
I had a look at the first merge commits. I did _not_ do a "git bisect&=
quot; but for
example a "git reset --hard 7af8a0f8088831428051976cb06cc1e450f8bab5&q=
uot; 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 comm=
it - 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 ou=
t to be
the first bad commit (glitches at 0 cpu load).
So all tested commits were pure merge commits.