From: Junio C Hamano Date: Sat, 10 Sep 2005 02:39:21 GMT Subject: Re: git-bisect failure Message-ID: <7virx9ir3a.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20050909011034.12f2bf64.akpm@osdl.org> bix:/usr/src/git26> git bisect bad Bisecting: 55 revisions left to test after this At this point, you marked 4c139862b8831261d57de02716b92f82e5fb463b "[PATCH] xtensa: delete accidental file" is already bad. And the last known good commit is b749bfcd1be72f8cb8310e1cac12825bda029432 "[PATCH] ppc64: update xmon helptext". The commit between these is just a straight sequence (no branches), so running "git bisect visualize" gives me a nice single strand of pearls. bix:/usr/src/git26> git bisect bad Bisecting: 28 revisions left to test after this With this, you marked "[PATCH] i386 boottime for_each_cpu broken" is bad. "Reread references" in the running gitk shows me that the range between bad and good halved. bix:/usr/src/git26> git bisect good Bisecting: 14 revisions left to test after this Marked "[PATCH] mips: remove timex.h for vr41xx" good. bix:/usr/src/git26> git bisect good Bisecting: 7 revisions left to test after this Marked "[PATCH] i386: cleanup serialize msr" good. bix:/usr/src/git26> git bisect good Bisecting: 3 revisions left to test after this Marked "[PATCH] x86: privilege cleanup" good. bix:/usr/src/git26> git bisect bad Bisecting: 2 revisions left to test after this Marked "[PATCH] x86: introduce a write acessor for updating the current LDT" bad. Just after you marked "[PATCH] x86: privilege cleanup" as good, the list of suspects looked like this (time flows bottom to top): bad [PATCH] i386 boottime for_each_cpu broken [PATCH] i386: encapsulate copying of pgd entries [PATCH] x86 NMI: better support for debuggers ??? [PATCH] x86: introduce a write acessor for updating the current LDT [PATCH] x86: remove redundant TSS clearing [PATCH] x86: make IOPL explicit good [PATCH] x86: privilege cleanup and you said the middle one is already bad here. We are tracking regression, so "privilege cleanup" was good and in the course of somewhere from there to "i386 boottime for_each_cpu broken" which is bad, a breakage happened. You marked the "updating the current LDT" one as bad, which to me looks like it was already broken at that point. After that, you say: bix:/usr/src/git26> git bisect good to mark "[PATCH] x86: remove redundant TSS clearing" as good, which means "redundant TSS" was good and "current LDT" was bad, and they are back to back, so it looks like the bug was introduced by the "LDT", which is what you got. So it _might_ be possible that you said "current LDT" was bad when it was actually good. That is one possible explanation. Another possibility is that the symptom you were tracking was not a single regression that was introduced with a single patch. Could it be possible that "the current LDT" did not pass your test but from different bug, which was fixed by either "x86 NMI" or "encapsulate copying pgd"? Sorry I am not a kernel developer so I cannot judge if the above is plausible or not. In any case, there is one caveat about bisection bug search. It assumes that you are tracking a single regression that was introduced, and there is no funny interaction of bugs hiding each other -- this may not hold true in the real life. IOW, something like this could be possible: BAD [PATCH] i386 boottime for_each_cpu broken good [PATCH] i386: encapsulate copying of pgd entries bad [PATCH] x86 NMI: better support for debuggers BAD [PATCH] x86: introduce a write acessor for updating the current LDT good [PATCH] x86: remove redundant TSS clearing good [PATCH] x86: make IOPL explicit GOOD [PATCH] x86: privilege cleanup I marked the ones bisect told you to test in Capital letters, and a good/bad which was never tested in lowercase. If the bug pattern is not "up to here everything is good but after that things start to break", then bisect, by its nature of skipping the check to narrow the range down fast, would miss the real transition from good to bad.