Re: 2.6.22-rc5 regression

From: Linus Torvalds
Date: Mon Jun 18 2007 - 13:03:05 EST




On Sun, 17 Jun 2007, Carlo Wood wrote:
>
> If you want my opinion on this: git bisect is broken :p
> I was very surprised that it printed this at this point.

Hmm. Possible. However, I *really* would need the git bisect log to see
what's up. So far, we have never seen a bug in "git bisect" that wasn't
either due to the user specifying path-names to limit the testing (and the
bug not being in that set of path-names), or the user not realizing that
with non-linear history the "git bisect" is actually a fairly complex op.

That said, "git bisect" _can_ give the "wrong" results in the sense that
the commit it points to may not be the one you are actually looking for,
if:

- the bug is sporadic, and not entirely repeatable, and a kernel you
marked as good wasn't really good, your test just didn't happen to
catch it that time around.

- the bug comes and goes, and the commit that "git bisect" pinpoints may
well *show* the bug, but may not be the *cause* of the bug (ie there
might be two or more independent things that have to come together for
the bug to trigger, and as a result there is not a "single" commit that
acts as a clear boundary)

But hey, a bug in "git bisect" is certainly _possible_. I just consider it
fairly unlikely by now.

> One bisect before, it said there were still 96 revision to check.
>
> Anyway - here are some facts of the kernels that I tested:

You seem to not actually have used "git bisect" to generate this list.

Quite frankly, the most likely cause for the bad bisection result is that
you have not used "git bisect" at all to let it pick the bisection points.
That really doesn't work. If you start giving "git bisect" points to test
that aren't "within" the space of points you had already told git bisect
about, you're no longer bisecting, you're giving it random points.

> I'd appreciate any suggestions or questions at this point, as I have no
> idea what to do next to find this problem.

If you do a real "git bisect", and don't just give it random points that
you want to check (you obviously _do_ need to give it one "good" and one
"bad" initially, but after that you *have* to pick a point that is within
the query space), you'll not get any sensible values out of git bisect.

"git bisect" will also give you a log in ".git/BISECT_LOG", which others
can use to follow your bisection. That might be useful to see.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/