Sean wrote:
On Sun, 05 Aug 2007 11:02:21 -0500
Larry Finger [off-list ref] wrote:
quoted
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
On Sun, 05 Aug 2007 14:24:06 -0500
Larry Finger [off-list ref] wrote:
Sean wrote:
quoted
On Sun, 05 Aug 2007 11:02:21 -0500
Larry Finger [off-list ref] wrote:
quoted
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
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