Problem with bisect

Problem with bisect

[Larry Finger]

I'm helping someone find what looks like a regression in bcm43xx-mac80211 between v2.6.22 and 
v2.6.23-rc1. This driver is not in the mainstream kernel, but is found in John Linville's 
wireless-dev git tree. When we do the first bisection between the current state and v2.6.22, we 
obtain a kernel whose Makefile says it is v2.6.22; however, it's code is based on a state before 
bcm43xx-mac80211 was introduced into this tree. My memory isn't what it used to be, but I think this 
code was put into this tree during 2.6.19 or .20. When I used visualize to see the tree, the bottom 
is all the way to v2.6.16, which I think is the origin of the git process.

Is this a git bug, or is it some flaw in this particular tree? We have worked around the problem by 
arbitrarily calling each bisection that does not have the bcm43xx-mac80211 code as "good". It has 
been a source of confusion for the guy I'm helping as it is his first bisection. Unfortunately, the 
bug doesn't show on my machine.

Thanks,

Larry

Re: Problem with bisect

[Larry Finger]

Sean wrote:
> On Sun, 05 Aug 2007 11:02:21 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
> 
>> I'm helping someone find what looks like a regression in bcm43xx-mac80211 between v2.6.22 and 
>> v2.6.23-rc1. This driver is not in the mainstream kernel, but is found in John Linville's 
>> wireless-dev git tree. When we do the first bisection between the current state and v2.6.22, we 
>> obtain a kernel whose Makefile says it is v2.6.22; however, it's code is based on a state before 
>> bcm43xx-mac80211 was introduced into this tree. My memory isn't what it used to be, but I think this 
>> code was put into this tree during 2.6.19 or .20. When I used visualize to see the tree, the bottom 
>> is all the way to v2.6.16, which I think is the origin of the git process.
>>
>> Is this a git bug, or is it some flaw in this particular tree? We have worked around the problem by 
>> arbitrarily calling each bisection that does not have the bcm43xx-mac80211 code as "good". It has 
>> been a source of confusion for the guy I'm helping as it is his first bisection. Unfortunately, the 
>> bug doesn't show on my machine.
>>

The git repo is git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git.

The commands were:

git bisect start
git bisect bad
git bisect good v2.6.22

I'm using git version 1.4.4.2.g04509

Larry

Re: Problem with bisect

[Thomas Glanzmann]

Hello,

> I'm using git version 1.4.4.2.g04509

1.4 has a issue with bisect at least the Debian 1.4 versio. Update to
1.5 and try again.

        Thomas

Re: Problem with bisect

[Larry Finger]

Thomas Glanzmann wrote:
> Hello,
> 
>> I'm using git version 1.4.4.2.g04509
> 
> 1.4 has a issue with bisect at least the Debian 1.4 versio. Update to
> 1.5 and try again.

I'm now using git version 1.5.3.rc4 and still have the same situation.

Larry

Re: Problem with bisect

[Sean]

On Sun, 05 Aug 2007 14:24:06 -0500
Larry Finger <larry.finger@lwfinger.net> wrote:

> Sean wrote:
> > On Sun, 05 Aug 2007 11:02:21 -0500
> > Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > 
> >> I'm helping someone find what looks like a regression in bcm43xx-mac80211 between v2.6.22 and 
> >> v2.6.23-rc1. This driver is not in the mainstream kernel, but is found in John Linville's 
> >> wireless-dev git tree. When we do the first bisection between the current state and v2.6.22, we 
> >> obtain a kernel whose Makefile says it is v2.6.22; however, it's code is based on a state before 
> >> bcm43xx-mac80211 was introduced into this tree. My memory isn't what it used to be, but I think this 
> >> code was put into this tree during 2.6.19 or .20. When I used visualize to see the tree, the bottom 
> >> is all the way to v2.6.16, which I think is the origin of the git process.
> >>
> >> Is this a git bug, or is it some flaw in this particular tree? We have worked around the problem by 
> >> arbitrarily calling each bisection that does not have the bcm43xx-mac80211 code as "good". It has 
> >> been a source of confusion for the guy I'm helping as it is his first bisection. Unfortunately, the 
> >> bug doesn't show on my machine.
> >>
> The git repo is git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git.
> 
> The commands were:
> 
> git bisect start
> git bisect bad
> git bisect good v2.6.22
> 
> I'm using git version 1.4.4.2.g04509

The directory "drivers/net/wireless/bcm43xx-mac80211" is only introduced in
commit v2.6.23-rc1-1621-gd05daff.   It didn't exist in v2.6.22.

You can see this with the command:

  $ git log -- drivers/net/wireless/bcm43xx-mac80211

Where the last listed commit is d05daff.  So of course there will be many
bisection points back to v2.6.22 where that directory just doesn't exist.
A bit of digging with Git shows this history for most of the files in
that directory:

  renamed in v2.6.23-rc1-1621 as bcm43xx-mac80211
  renamed in v2.6.21-rc1-809 as mac80211
  renamed in v2.6.17-rc2-357 as d80211/bcm43xx
 Imported in v2.6.16-1725 as bcm43xx-d80211

HTH,
Sean

Re: Problem with bisect

[Larry Finger]

Sean wrote:
> 
> The directory "drivers/net/wireless/bcm43xx-mac80211" is only introduced in
> commit v2.6.23-rc1-1621-gd05daff.   It didn't exist in v2.6.22.
> 
> You can see this with the command:
> 
>   $ git log -- drivers/net/wireless/bcm43xx-mac80211
> 
> Where the last listed commit is d05daff.  So of course there will be many
> bisection points back to v2.6.22 where that directory just doesn't exist.
> A bit of digging with Git shows this history for most of the files in
> that directory:
> 
>   renamed in v2.6.23-rc1-1621 as bcm43xx-mac80211
>   renamed in v2.6.21-rc1-809 as mac80211
>   renamed in v2.6.17-rc2-357 as d80211/bcm43xx
>  Imported in v2.6.16-1725 as bcm43xx-d80211

Thanks for the response. Obviously the  difficulties were due to the structure of the tree. This 
chunk of code has had a varied history.

Larry

Re: Problem with bisect

[Christian Couder]

Le dimanche 5 août 2007 18:02, Larry Finger a écrit :
> I'm helping someone find what looks like a regression in bcm43xx-mac80211
> between v2.6.22 and v2.6.23-rc1. This driver is not in the mainstream
> kernel, but is found in John Linville's wireless-dev git tree. When we do
> the first bisection between the current state and v2.6.22, we obtain a
> kernel whose Makefile says it is v2.6.22; however, it's code is based on
> a state before bcm43xx-mac80211 was introduced into this tree. 

You use "git bisect good v2.6.22", but this is not true because the 
tag "v2.6.22" is on the mainstream kernel branch and the driver is not 
there.

If the v2.6.22 kernel that used to work came directly from John Linville's 
wireless-dev git tree, not from a patch, then you should find the exact 
commit in John Linville's tree that worked and say "git bisect good <this 
commit>".

But if the driver that worked with a mainstream v2.6.22 kernel had been 
patched, and now doesn't work when the same patch is applied to mainstream 
v2.6.23-rc1 kernel, then you can perhaps use:

git bisect start
git bisect bad v2.6.23-rc1
git bisect good v2.6.22

and then:

1) patch the kernel with the driver patch,
2) test the patched kernel,
3) remove the patch,
4) say "git bisect good" or "git bisect bad"
5) go to step 1) until the commit that broke the driver is found

Best regards,
Christian.

Re: Problem with bisect

[Larry Finger]

Christian Couder wrote:
> 
> You use "git bisect good v2.6.22", but this is not true because the 
> tag "v2.6.22" is on the mainstream kernel branch and the driver is not 
> there.
> 
> If the v2.6.22 kernel that used to work came directly from John Linville's 
> wireless-dev git tree, not from a patch, then you should find the exact 
> commit in John Linville's tree that worked and say "git bisect good <this 
> commit>".
> 
> But if the driver that worked with a mainstream v2.6.22 kernel had been 
> patched, and now doesn't work when the same patch is applied to mainstream 
> v2.6.23-rc1 kernel, then you can perhaps use:
> 
> git bisect start
> git bisect bad v2.6.23-rc1
> git bisect good v2.6.22
> 
> and then:
> 
> 1) patch the kernel with the driver patch,
> 2) test the patched kernel,
> 3) remove the patch,
> 4) say "git bisect good" or "git bisect bad"
> 5) go to step 1) until the commit that broke the driver is found

Has the ability to use a commit hash to indicate a start point been in git for a long time? I think 
I remember trying it before when a version tag had not been downloaded and having a failure.

Larry

Re: Problem with bisect

[Christian Couder]

Le mardi 7 août 2007 04:53, Larry Finger a écrit :
>
> Has the ability to use a commit hash to indicate a start point been in
> git for a long time?

Yes, it has always been there.

> I think I remember trying it before when a version 
> tag had not been downloaded and having a failure.

It should have worked.

Best regards,
Christian.