On Fri, May 13, 2011 at 9:38 AM, Andrew Lutomirski [off-list ref] wrote:

On Fri, May 13, 2011 at 4:20 AM, Christian Couder
[off-list ref] wrote:

quoted

On Thu, May 12, 2011 at 7:15 PM, Andrew Lutomirski [off-list ref] wrote:

quoted

OK, this sucks.  In the course of bisecting this, I've hit two other
apparently unrelated bugs that prevent my from testing large numbers
of kernels.  Do I have two questions:

1. Anyone have any ideas from looking at the log?

It looks like most of what's left is network code, so cc netdev.

2.  The !&$#@ bisection is skipping all over the place.  I've seen
2.6.37 versions and all manner of -rc's out of order.  Linus, and
other people who like pontificating about git bisection: is there any
way to get the bisection to follow Linus' tree?  I think that if
bisect could be persuaded to consider only changes that are reached by
following only the *first* merge parent all the way from the bad
revision to the good revision, then the bisection would build versions
that were at least good enough for Linus to pull and might have fewer
bisection-killing bugs.

(This isn't a new idea [1], and git rev-list --bisect --first-parent
isn't so bad except that it doesn't bisect.)

Did you forget to put the reference [1] in your email? Was it this one
you were thinking about:

http://thread.gmane.org/gmane.comp.version-control.git/165433/

No, it was this:

http://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches

Sadly even that's not enough.  I finished the bisection (by
standard-ish techniques but with a bit of overriding of git bisect's
choices and occasional merging of newer versions of -linus to get
something that would boot) and it pointed to a commit that wasn't the
culprit.

The problem is that 2.6.39-rc7 is bad, 2.6.38 (and 2.6.38.{5,6}) is
good, but 2.6.38-rc5 is bad and fails identically to 2.6.39-rc7.  I
think that git bisect makes the assumption that ancestors of a good
commit are good, and that just isn't true for this bug.

So what I really want is a fancy version of git bisect that makes no
assumptions about the relationship of good and bad commits in the
graph and just finds me a commit that is bad but for which all parents
are good or vice versa.

I'm currently bisecting the other way to find the commit before 2.6.38
that fixed the bug, since there's presumably less churn there than in
the early bits of 2.6.39.

--Andy