threads / discuss / 9396

Problem with bisect

Subject: Problem with bisect

## tl;dr

9 messages between Aug 5, 2007 and Aug 7, 2007.

replies: 8people: 4as markdown or json

Larry Finger· Aug 5, 2007, 16:02 UTC · lore

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
Christian Couder· Aug 7, 2007, 01:50 UTC · re: Larry Finger · lore

Re: Problem with bisect

Le dimanche 5 août 2007 18:02, Larry Finger a écrit :
Show 6 quoted lines
> 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.

Larry Finger· Aug 7, 2007, 02:53 UTC · re: Christian Couder · lore

Re: Problem with bisect

Christian Couder wrote:
Show 25 quoted lines
> 
> 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
Christian Couder· Aug 7, 2007, 05:26 UTC · re: Larry Finger · lore

Re: Problem with bisect

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.

Larry Finger· Aug 5, 2007, 19:24 UTC · lore

Re: Problem with bisect

Sean wrote:
Show 16 quoted lines
> 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
Larry Finger· Aug 5, 2007, 20:33 UTC · re: Thomas Glanzmann · lore

Re: Problem with bisect

Thomas Glanzmann wrote:
Show 6 quoted lines
> 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
Sean· Aug 6, 2007, 18:12 UTC · re: Larry Finger · lore

Re: Problem with bisect

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

Show 26 quoted lines
> 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

Larry Finger· Aug 6, 2007, 18:37 UTC · re: Sean · lore

Re: Problem with bisect

Sean wrote:
Show 17 quoted lines
> 
> 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

← back to recent threads