Re: git-bisect failure

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.