Problem with git bisect between 2.6.15 and 2.6.16

Problem with git bisect between 2.6.15 and 2.6.16

[Greg Lee]

I get the following when I try to git bisect between 2.6.15 and 2.6.16:
 
[root@Fedora-test tmp]# git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
[root@Fedora-test linux-git]# git bisect start
[root@Fedora-test linux-git]# cd linux-git
[root@Fedora-test linux-git]# git bisect good v2.6.16
[root@Fedora-test linux-git]# git bisect bad v2.6.15
dab47a31f42a23d2b374e1cd7d0b797e8e08b23d was both good and bad

What is the proper method to do a bisect between 2.6.15 and 2.6.16?

Greg

Re: Problem with git bisect between 2.6.15 and 2.6.16

[sean]

On Mon, 27 Mar 2006 19:00:25 -0500
"Greg Lee" <glee@casabyte.com> wrote:

> I get the following when I try to git bisect between 2.6.15 and 2.6.16:
>  
> [root@Fedora-test tmp]# git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
> [root@Fedora-test linux-git]# git bisect start
> [root@Fedora-test linux-git]# cd linux-git
> [root@Fedora-test linux-git]# git bisect good v2.6.16
> [root@Fedora-test linux-git]# git bisect bad v2.6.15
> dab47a31f42a23d2b374e1cd7d0b797e8e08b23d was both good and bad
> 
> What is the proper method to do a bisect between 2.6.15 and 2.6.16?
> 

You need to do the bisect start after you cd into the linux-git 
directory.   Also, it appears you have the good and bad reversed,
presumably the newer (v2.6.16) is bad, and the older (v.2.6.15)
is good.

Sean

RE: Problem with git bisect between 2.6.15 and 2.6.16

[Greg Lee]

> You need to do the bisect start after you cd into the linux-git 
> directory.

Sorry, cut and paste error, I did the cd before the bisect:

[root@Fedora-test git]# git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git-fresh
[root@Fedora-test git]# cd linux-git-fresh/
[root@Fedora-test linux-git-fresh]# git bisect start
[root@Fedora-test linux-git-fresh]# git bisect bad v2.6.15
[root@Fedora-test linux-git-fresh]# git bisect good v2.6.16
dab47a31f42a23d2b374e1cd7d0b797e8e08b23d was both good and bad

> Also, it appears you have the good and bad reversed,
> presumably the newer (v2.6.16) is bad, and the older (v.2.6.15)
> is good.

No, the problem was fixed in 2.6.16 and I'm trying to figure out what fixed it so that I
can back-port the fix into a previous kernel version, so 2.6.16 is good and 2.6.15 is bad.

Greg

Re: Problem with git bisect between 2.6.15 and 2.6.16

[Tony Luck]

> No, the problem was fixed in 2.6.16 and I'm trying to figure out what fixed it so that I
> can back-port the fix into a previous kernel version, so 2.6.16 is good and 2.6.15 is bad.

You'll need to invert "good" and bad" for this.  I.e. mark 2.6.15 as
good, 2.6.16 as bad, and
then as you test mark kernels with the bug as good, and ones without
as bad.  Try not to go
insane while working in this inverted parallel universe :-)

-Tony

RE: Problem with git bisect between 2.6.15 and 2.6.16

[Greg Lee]

> You'll need to invert "good" and bad" for this.  I.e. mark 2.6.15 as good, 2.6.16 as
bad, and
> then as you test mark kernels with the bug as good, and ones without as bad.  Try not to
go
> insane while working in this inverted parallel universe :-)
> 
> -Tony

This was progressing fine until I ran into an issue that makes the kernel unstable causing
it to crash at semi-random times.  I'm down to about 350 commits left in the bisect.  I've
tried:

git reset --hard HEAD~3

no luck, same problem, unstable

then I tried --hard HEAD~50

no luck, same problem, unstable

I'm concerned about moving too much further in the "~" direction, will this cause me other
problems?

Greg

RE: Problem with git bisect between 2.6.15 and 2.6.16

[Luck, Tony]

 
> This was progressing fine until I ran into an issue that makes the kernel unstable causing
> it to crash at semi-random times.  I'm down to about 350 commits left in the bisect.  I've
> tried:
> 
> git reset --hard HEAD~3
>
>no luck, same problem, unstable

You can try "git bisect visualize" to invoke gitk on the remaining commits, and
then pick a likely looking stable point for your next test.  This is documented
reasonably well in the git Documentation/howto/isolate-bugs-with-bisect.txt

-Tony