kernel git bisect question

kernel git bisect question

[Mark Hounschell]

Between git bisect [good | bad ]s should I always "make clean" or can I
count on the build system to take care of everything properly?

Thanks
Mark

Re: kernel git bisect question

[Sam Ravnborg]

On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
> Between git bisect [good | bad ]s should I always "make clean" or can I
> count on the build system to take care of everything properly?

You can count on the build system to take care.
It is very rare that the build system does not handle this.

Lately we fixed a bug where we did not properly handled when a file
was renamed from *.S to *.c. But you will most likely not hit this.

	Sam

Re: kernel git bisect question

[Mark Hounschell]

On 03/10/2011 04:14 PM, Sam Ravnborg wrote:
> On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
>> Between git bisect [good | bad ]s should I always "make clean" or can I
>> count on the build system to take care of everything properly?
> 
> You can count on the build system to take care.
> It is very rare that the build system does not handle this.
> 
> Lately we fixed a bug where we did not properly handled when a file
> was renamed from *.S to *.c. But you will most likely not hit this.
> 
> 	Sam
> .
> 

Thanks

Mark

Re: kernel git bisect question

[Steven Rostedt]

On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
> Between git bisect [good | bad ]s should I always "make clean" or can I
> count on the build system to take care of everything properly?

I don't usually do a make clean. Although my ktest.pl (see tools/testing/ktest)
does do a make mrproper between builds (unless you specify not to).

There are some cases in the kernel that can cause bugs if you do not do
a make clean, so if your bisect hits one of those rare cases, you may
introduce a bug in the build. But that is extremely rare. Like I said, when I use to
do manual git bisects, I never did a make clean. But now that I do
automate bisects, and do not need to babysit the box, I let ktest do
those cleans.

-- Steve

Re: kernel git bisect question

[Mark Hounschell]

On 03/10/2011 04:54 PM, Steven Rostedt wrote:
> On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
>> Between git bisect [good | bad ]s should I always "make clean" or can I
>> count on the build system to take care of everything properly?
> 

I'm trying to bisect between 2.6.35 and 2.6.36. What have I done wrong?
Here is exactly what I've done. Why after my second "git bisect bad" do
I get a Makefile for 2.6.35-rc1 and then after the fourth I get a Makefile
for 2.6.34??
 

harley:/usr/src # git clone git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
Initialized empty Git repository in /usr/src/linux-2.6-allstable/.git/
remote: Counting objects: 1971777, done.
remote: Compressing objects: 100% (332768/332768), done.
remote: Total 1971777 (delta 1640306), reused 1952128 (delta 1621734)
Receiving objects: 100% (1971777/1971777), 402.59 MiB | 2.15 MiB/s, done.
Resolving deltas: 100% (1640306/1640306), done.

harley:/usr/src # cd linux-2.6-allstable
harley:/usr/src/linux-2.6-allstable # git bisect start
harley:/usr/src/linux-2.6-allstable # git bisect bad v2.6.36
harley:/usr/src/linux-2.6-allstable # git bisect good v2.6.35
Bisecting: 5103 revisions left to test after this (roughly 12 steps)
[78417334b5cb6e1f915b8fdcc4fce3f1a1b4420c] Merge branch 'bkl/core' of git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing


harley:/usr/src/linux-2.6-allstable # git bisect bad
Bisecting: 2414 revisions left to test after this (roughly 11 steps)
[6ba74014c1ab0e37af7de6f64b4eccbbae3cb9e7] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6


harley:/usr/src/linux-2.6-allstable # git bisect bad       (Why did this one give me a 2.6.35-rc1 Makefile)
Bisecting: 1366 revisions left to test after this (roughly 10 steps)
[b7753c8cd51dce67a0b152efb456a21ff1cc241b] cfg80211: fix dev <-> wiphy typo


harley:/usr/src/linux-2.6-allstable # git bisect bad       (Still a 2.6.35-rc1 Makefile)
Bisecting: 643 revisions left to test after this (roughly 9 steps)
[ef2519b1dd3994074e3e438d67f2d91d07c3a5a8] netxen: fail when try to setup unsupported features


harley:/usr/src/linux-2.6-allstable # git bisect bad       (Still a 2.6.35-rc1 Makefile)
Bisecting: 319 revisions left to test after this (roughly 8 steps)
[14599f1e341ee219abdd15f4eee5872d6f2d29f1] Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next-2.6


harley:/usr/src/linux-2.6-allstable # git bisect bad       (Why did this one give me a 2.6.34 Makefile)
Bisecting: 161 revisions left to test after this (roughly 7 steps)
[86cc652dfe57f365533cf2e64e08ff37a510d42e] iwlwifi: remove debug frame dumping


Thanks again
Mark

Re: kernel git bisect question

[Sam Ravnborg]

On Fri, Mar 11, 2011 at 01:31:53PM -0500, Mark Hounschell wrote:
> On 03/10/2011 04:54 PM, Steven Rostedt wrote:
> > On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
> >> Between git bisect [good | bad ]s should I always "make clean" or can I
> >> count on the build system to take care of everything properly?
> > 
> 
> I'm trying to bisect between 2.6.35 and 2.6.36. What have I done wrong?
> Here is exactly what I've done. Why after my second "git bisect bad" do
> I get a Makefile for 2.6.35-rc1 and then after the fourth I get a Makefile
> for 2.6.34??

The development is not linear.
So you see a commit developed on top of 2.6.34 that was included in 2.6.35.
This is normal.

	Sam

Re: kernel git bisect question

[Mark Hounschell]

On 03/11/2011 01:37 PM, Sam Ravnborg wrote:
> On Fri, Mar 11, 2011 at 01:31:53PM -0500, Mark Hounschell wrote:
>> On 03/10/2011 04:54 PM, Steven Rostedt wrote:
>>> On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
>>>> Between git bisect [good | bad ]s should I always "make clean" or can I
>>>> count on the build system to take care of everything properly?
>>>
>>
>> I'm trying to bisect between 2.6.35 and 2.6.36. What have I done wrong?
>> Here is exactly what I've done. Why after my second "git bisect bad" do
>> I get a Makefile for 2.6.35-rc1 and then after the fourth I get a Makefile
>> for 2.6.34??
> 
> The development is not linear.
> So you see a commit developed on top of 2.6.34 that was included in 2.6.35.
> This is normal.
> 

OK, thanks again. I'll continue on with the process then.

Mark

Re: kernel git bisect question

[Steven Rostedt]

On Fri, 2011-03-11 at 19:37 +0100, Sam Ravnborg wrote:
> On Fri, Mar 11, 2011 at 01:31:53PM -0500, Mark Hounschell wrote:
> > On 03/10/2011 04:54 PM, Steven Rostedt wrote:
> > > On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
> > >> Between git bisect [good | bad ]s should I always "make clean" or can I
> > >> count on the build system to take care of everything properly?
> > > 
> > 
> > I'm trying to bisect between 2.6.35 and 2.6.36. What have I done wrong?
> > Here is exactly what I've done. Why after my second "git bisect bad" do
> > I get a Makefile for 2.6.35-rc1 and then after the fourth I get a Makefile
> > for 2.6.34??
> 
> The development is not linear.
> So you see a commit developed on top of 2.6.34 that was included in 2.6.35.
> This is normal.

Right.

Mark, don't be embarrassed, this is a common question for those that
start using git bisect. Because of the way git merges branches, you may
end up in an old version of a kernel, while looking between two newer
versions.



    v2.6.36
        |
        +
        |\
        | \
v2.6.35 +  \
        |   +---- developers branch
        |  /
        | /
        |/
        +--- v 2.6.34
        |

If a developer branched off of 2.6.34 and then his work got merged after
v2.6.35, your bisect may easily go into that developers branch between
2.6.35 and 2.6.36, where you will suddenly see 2.6.34 appear and
disappear within bisect iterations. IOW, don't trust what you see in the
Makefile ;)

Understand?

-- Steve

Re: kernel git bisect question

[Mark Hounschell]

On 03/11/2011 01:51 PM, Steven Rostedt wrote:
> On Fri, 2011-03-11 at 19:37 +0100, Sam Ravnborg wrote:
>> On Fri, Mar 11, 2011 at 01:31:53PM -0500, Mark Hounschell wrote:
>>> On 03/10/2011 04:54 PM, Steven Rostedt wrote:
>>>> On Thu, Mar 10, 2011 at 03:27:00PM -0500, Mark Hounschell wrote:
>>>>> Between git bisect [good | bad ]s should I always "make clean" or can I
>>>>> count on the build system to take care of everything properly?
>>>>
>>>
>>> I'm trying to bisect between 2.6.35 and 2.6.36. What have I done wrong?
>>> Here is exactly what I've done. Why after my second "git bisect bad" do
>>> I get a Makefile for 2.6.35-rc1 and then after the fourth I get a Makefile
>>> for 2.6.34??
>>
>> The development is not linear.
>> So you see a commit developed on top of 2.6.34 that was included in 2.6.35.
>> This is normal.
> 
> Right.
> 
> Mark, don't be embarrassed, this is a common question for those that
> start using git bisect. Because of the way git merges branches, you may
> end up in an old version of a kernel, while looking between two newer
> versions.
> 
> 
> 
>     v2.6.36
>         |
>         +
>         |\
>         | \
> v2.6.35 +  \
>         |   +---- developers branch
>         |  /
>         | /
>         |/
>         +--- v 2.6.34
>         |
> 
> If a developer branched off of 2.6.34 and then his work got merged after
> v2.6.35, your bisect may easily go into that developers branch between
> 2.6.35 and 2.6.36, where you will suddenly see 2.6.34 appear and
> disappear within bisect iterations. IOW, don't trust what you see in the
> Makefile ;)
> 
> Understand?
> 

Understood. I was starting to think it was me. Thanks.

Mark