Git puzzle

Git puzzle

[Gene Heskett]

Hey guys, I need to setup a bisect using git but the man pages aren't 
giving me what I need to know.  Mainly I have no clue what the URL for the 
git repos looks like, I've been downloading and building the tarballs from 
kernel.org all this time.

Assuming I start with fresh git pull of 3.8.2 which worked, working toward 
3.8.3 which doesn't, and I have the disk space chowned to me, what is the 
exact syntax to pull a clone of 3.8.2, and then do a bisect to 3.8.3 where 
the microcode update for an AMD phenom doesn't work. Skipping fwd to 3.12.0 
it still isn't working.

Thanks for any help.  And Linus, it you're copying this list, happy 44th 
birthday today.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Congratulations are in order for Tom Reid.

He says he just found out he is the winner of the 2021 Psychic of the
Year award.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.

Re: Git puzzle

[Jason Cooper]

Hey Gene,

On Sat, Dec 28, 2013 at 09:41:40PM -0500, Gene Heskett wrote:
> Hey guys, I need to setup a bisect using git but the man pages aren't 
> giving me what I need to know.  Mainly I have no clue what the URL for the 
> git repos looks like, I've been downloading and building the tarballs from 
> kernel.org all this time.

Looks like you now have your driving problem to learn git. ;-)

> Assuming I start with fresh git pull of 3.8.2 which worked,

Here's where the wheels come off the cart.  You aren't cloning a specific
revision/tag/version.  'git clone' makes a clone (hence the name) of the
entire tree's history.  Once you have a clone on your local disk, you
can then checkout _any_ version you want.  You have *all* of them.  This
is what 'git bisect' will be doing for you.

> working toward 3.8.3 which doesn't, and I have the disk space chowned
> to me, what is the exact syntax to pull a clone of 3.8.2, and then do
> a bisect to 3.8.3 where the microcode update for an AMD phenom doesn't
> work. Skipping fwd to 3.12.0 it still isn't working.

The version tags you are referring to are from the linux-stable tree, so
we'll clone that one instead of Linus'.

So, something like this:

$ git clone \
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git \
~/linux-stable

$ cd ~/linux-stable
$ git checkout v3.8.3
$ git bisect start
$ git bisect bad
$ git bisect good v3.8.2
$ ...

And now you iterate through as the manpage suggests, until it narrows it
down to a single commit.  Once there, report to this list with '[BUG
BISECTED] ...' in the subject line.

hth,

Jason.

Re: Git puzzle

[Jason Cooper]

Gene,

On Sat, Dec 28, 2013 at 11:35:47PM -0500, Jason Cooper wrote:
> On Sat, Dec 28, 2013 at 09:41:40PM -0500, Gene Heskett wrote:
...
> > working toward 3.8.3 which doesn't, and I have the disk space chowned
> > to me, what is the exact syntax to pull a clone of 3.8.2, and then do
> > a bisect to 3.8.3 where the microcode update for an AMD phenom doesn't
> > work. Skipping fwd to 3.12.0 it still isn't working.
> 
> The version tags you are referring to are from the linux-stable tree, so
> we'll clone that one instead of Linus'.

Just one small addendum to this:

Once you've identified the commit in the -stable tree, we'll have to
find the corresponding commit in the mainline tree.  Don't worry about
trying to find this for your initial email, just make sure to mention
that the commit identified is from the -stable tree between v3.8.2 and
v3.8.3.

thx,

Jason.

Re: Git puzzle

[Gene Heskett]

On Saturday 28 December 2013, Jason Cooper wrote:
>Hey Gene,
>
>On Sat, Dec 28, 2013 at 09:41:40PM -0500, Gene Heskett wrote:
>> Hey guys, I need to setup a bisect using git but the man pages aren't
>> giving me what I need to know.  Mainly I have no clue what the URL for
>> the git repos looks like, I've been downloading and building the
>> tarballs from kernel.org all this time.
>
>Looks like you now have your driving problem to learn git. ;-)
>
>> Assuming I start with fresh git pull of 3.8.2 which worked,
>
>Here's where the wheels come off the cart.  You aren't cloning a specific
>revision/tag/version.  'git clone' makes a clone (hence the name) of the
>entire tree's history.  Once you have a clone on your local disk, you
>can then checkout _any_ version you want.  You have *all* of them.  This
>is what 'git bisect' will be doing for you.
>
>> working toward 3.8.3 which doesn't, and I have the disk space chowned
>> to me, what is the exact syntax to pull a clone of 3.8.2, and then do
>> a bisect to 3.8.3 where the microcode update for an AMD phenom doesn't
>> work. Skipping fwd to 3.12.0 it still isn't working.
>
>The version tags you are referring to are from the linux-stable tree, so
>we'll clone that one instead of Linus'.
>
>So, something like this:
>
>$ git clone \
>git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git \
>~/linux-stable

Looks like its working.

>$ cd ~/linux-stable
>$ git checkout v3.8.3
>$ git bisect start
>$ git bisect bad
>$ git bisect good v3.8.2
>$ ...
>
>And now you iterate through as the manpage suggests, until it narrows it
>down to a single commit.  Once there, report to this list with '[BUG
>BISECTED] ...' in the subject line.
>
>hth,

Yes, I think I can nail it now.  One final clarification, do I use a 
.config geared more to my machine, or am I supposed to do a "make 
allmodconfig?"

I haven't done this in a while and I'm still going thru the xconfig, 
stripping out modules for hardware I don't have, but if I just transfer the 
old ones in, they should work but will be building about 1400 modules 
extra.

I just got the 2nd message about marking the subject line, can do, thanks.

Thanks Jason.

>Jason.


Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

BOFH excuse #8:

static buildup
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.

Re: Git puzzle

[Jason Cooper]

Gene,

On Sun, Dec 29, 2013 at 12:11:26AM -0500, Gene Heskett wrote:
> On Saturday 28 December 2013, Jason Cooper wrote:
> >On Sat, Dec 28, 2013 at 09:41:40PM -0500, Gene Heskett wrote:
...
> >> working toward 3.8.3 which doesn't, and I have the disk space chowned
> >> to me, what is the exact syntax to pull a clone of 3.8.2, and then do
> >> a bisect to 3.8.3 where the microcode update for an AMD phenom doesn't
> >> work. Skipping fwd to 3.12.0 it still isn't working.
> >
> >The version tags you are referring to are from the linux-stable tree, so
> >we'll clone that one instead of Linus'.
> >
> >So, something like this:
> >
> >$ git clone \
> >git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git \
> >~/linux-stable
> 
> Looks like its working.
> 
> >$ cd ~/linux-stable
> >$ git checkout v3.8.3
> >$ git bisect start
> >$ git bisect bad
> >$ git bisect good v3.8.2
> >$ ...
> >
> >And now you iterate through as the manpage suggests, until it narrows it
> >down to a single commit.  Once there, report to this list with '[BUG
> >BISECTED] ...' in the subject line.
> >
> >hth,
> 
> Yes, I think I can nail it now.  One final clarification, do I use a 
> .config geared more to my machine, or am I supposed to do a "make 
> allmodconfig?"

I would use the smallest config that allows me to boot the system and
reproduce the bug.  A good starting point is /proc/config.gz from the
running system.  allmodconfig is just sticking the knife in and
twisting unnecessarily.

> I haven't done this in a while and I'm still going thru the xconfig, 
> stripping out modules for hardware I don't have, but if I just transfer the 
> old ones in, they should work but will be building about 1400 modules 
> extra.

You may want to try the opposite approach.  x86_64_defconfig, then add just
what is necessary to boot and reproduce the bug.

hth,

Jason.

Re: Git puzzle

[Gene Heskett]

On Sunday 29 December 2013, Jason Cooper wrote:
>Gene,
>
>On Sun, Dec 29, 2013 at 12:11:26AM -0500, Gene Heskett wrote:
>> On Saturday 28 December 2013, Jason Cooper wrote:
>> >On Sat, Dec 28, 2013 at 09:41:40PM -0500, Gene Heskett wrote:
>...
>
>> >> working toward 3.8.3 which doesn't, and I have the disk space
>> >> chowned to me, what is the exact syntax to pull a clone of 3.8.2,
>> >> and then do a bisect to 3.8.3 where the microcode update for an AMD
>> >> phenom doesn't work. Skipping fwd to 3.12.0 it still isn't working.
>> >
>> >The version tags you are referring to are from the linux-stable tree,
>> >so we'll clone that one instead of Linus'.
>> >
>> >So, something like this:
>> >
>> >$ git clone \
>> >git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>> >\ ~/linux-stable
>> 
>> Looks like its working.
>> 
>> >$ cd ~/linux-stable
>> >$ git checkout v3.8.3
>> >$ git bisect start
>> >$ git bisect bad
>> >$ git bisect good v3.8.2
>> >$ ...
>> >
>> >And now you iterate through as the manpage suggests, until it narrows
>> >it down to a single commit.  Once there, report to this list with
>> >'[BUG BISECTED] ...' in the subject line.
>> >
>> >hth,
>> 
>> Yes, I think I can nail it now.  One final clarification, do I use a
>> .config geared more to my machine, or am I supposed to do a "make
>> allmodconfig?"
>
>I would use the smallest config that allows me to boot the system and
>reproduce the bug.  A good starting point is /proc/config.gz from the
>running system.  allmodconfig is just sticking the knife in and
>twisting unnecessarily.

That was my thinking. So I asked. :)

>> I haven't done this in a while and I'm still going thru the xconfig,
>> stripping out modules for hardware I don't have, but if I just transfer
>> the old ones in, they should work but will be building about 1400
>> modules extra.
>
>You may want to try the opposite approach.  x86_64_defconfig, then add
>just what is necessary to boot and reproduce the bug.

Oh-oh, and where in this new tree do I find that?  Or is that a make 
command?

I use a script called makeit, does everything but the grub-update.  
Designed to stop if it encounters an error so the error doesn't scroll off 
screen.

Thanks. 
>
>hth,
>
>Jason.


Cheers, Gene

Re: Git puzzle

[Jason Cooper]

On Sun, Dec 29, 2013 at 12:42:00AM -0500, Gene Heskett wrote:
> On Sunday 29 December 2013, Jason Cooper wrote:
...
> >You may want to try the opposite approach.  x86_64_defconfig, then add
> >just what is necessary to boot and reproduce the bug.
> 
> Oh-oh, and where in this new tree do I find that?  Or is that a make 
> command?

$ make x86_64_defconfig

thx,

Jason.

Re: Git puzzle

[Gene Heskett]

On Sunday 29 December 2013, Jason Cooper wrote:
>Gene,
>
>On Sun, Dec 29, 2013 at 12:11:26AM -0500, Gene Heskett wrote:
>> On Saturday 28 December 2013, Jason Cooper wrote:
>> >On Sat, Dec 28, 2013 at 09:41:40PM -0500, Gene Heskett wrote:
>...
>
>> >> working toward 3.8.3 which doesn't, and I have the disk space
>> >> chowned to me, what is the exact syntax to pull a clone of 3.8.2,
>> >> and then do a bisect to 3.8.3 where the microcode update for an AMD
>> >> phenom doesn't work. Skipping fwd to 3.12.0 it still isn't working.
>> >
>> >The version tags you are referring to are from the linux-stable tree,
>> >so we'll clone that one instead of Linus'.
>> >
>> >So, something like this:
>> >
>> >$ git clone \
>> >git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
>> >\ ~/linux-stable
>> 
>> Looks like its working.
>> 
>> >$ cd ~/linux-stable
>> >$ git checkout v3.8.3
>> >$ git bisect start
>> >$ git bisect bad
>> >$ git bisect good v3.8.2
>> >$ ...
>> >
>> >And now you iterate through as the manpage suggests, until it narrows
>> >it down to a single commit.  Once there, report to this list with
>> >'[BUG BISECTED] ...' in the subject line.
>> >
>> >hth,
>> 
>> Yes, I think I can nail it now.  One final clarification, do I use a
>> .config geared more to my machine, or am I supposed to do a "make
>> allmodconfig?"
>
>I would use the smallest config that allows me to boot the system and
>reproduce the bug.  A good starting point is /proc/config.gz from the
>running system.  allmodconfig is just sticking the knife in and
>twisting unnecessarily.
>
>> I haven't done this in a while and I'm still going thru the xconfig,
>> stripping out modules for hardware I don't have, but if I just transfer
>> the old ones in, they should work but will be building about 1400
>> modules extra.
>
>You may want to try the opposite approach.  x86_64_defconfig, then add
>just what is necessary to boot and reproduce the bug.
>
>hth,
>
>Jason.

Did that, then added some stuff for my hdwe, made sure the Makefile version 
and my makeit script versions matched. Fired off my build/install script, 
But it bailed out at the mkinitramfs stage, couldn't find 
/lib/modules/3.8.2 because it was named "3.8.2+".

So how does this work?  snilmerg? git playing in the sandbox somehow?  I'm 
going to see about some sleep in the meantime as its 1:30 Am here in WV, 
USA now.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Living in New York City gives people real incentives to want things that
nobody else wants.
		-- Andy Warhol
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.

Re: Git puzzle

[Jason Cooper]

On Sun, Dec 29, 2013 at 01:27:05AM -0500, Gene Heskett wrote:
> On Sunday 29 December 2013, Jason Cooper wrote:
...
> >You may want to try the opposite approach.  x86_64_defconfig, then add
> >just what is necessary to boot and reproduce the bug.
> 
> Did that, then added some stuff for my hdwe, made sure the Makefile version 
> and my makeit script versions matched. Fired off my build/install script, 
> But it bailed out at the mkinitramfs stage, couldn't find 
> /lib/modules/3.8.2 because it was named "3.8.2+".

For this bisect run, can you do without the initramfs?  Just build the
sata driver and the fs driver into the kernel.  You may want to drop
makeit and just do the bare minimum, 'make bzImage && make modules &&
make modules_install' or similar.

The '+' means the kernel build system (using git) determined that there
were changes to the source tree from the most recent tagged version.  If
there weren't, it would just use the tag 3.8.2.  You can take a look at
scripts/setlocalversion to see how it figures it out.

hth,

Jason.

Re: Git puzzle

[Geert Uytterhoeven]

Hi Gene,

On Sun, Dec 29, 2013 at 6:11 AM, Gene Heskett <gheskett@wdtv.com> wrote:
> Yes, I think I can nail it now.  One final clarification, do I use a
> .config geared more to my machine, or am I supposed to do a "make
> allmodconfig?"
>
> I haven't done this in a while and I'm still going thru the xconfig,
> stripping out modules for hardware I don't have, but if I just transfer the
> old ones in, they should work but will be building about 1400 modules
> extra.

If you're using ccache ('make CROSS_COMPILE="ccache "'), it may be
much faster to just build everything, than to try to find a config subset that
contains everything you need. And the further in the bisection process, the
less that needs to be recompiled.

Good luck!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Git puzzle

[Gene Heskett]

On Sunday 29 December 2013, Jason Cooper wrote:
>On Sun, Dec 29, 2013 at 01:27:05AM -0500, Gene Heskett wrote:
>> On Sunday 29 December 2013, Jason Cooper wrote:
>...
>
>> >You may want to try the opposite approach.  x86_64_defconfig, then add
>> >just what is necessary to boot and reproduce the bug.
>> 
>> Did that, then added some stuff for my hdwe, made sure the Makefile
>> version and my makeit script versions matched. Fired off my
>> build/install script, But it bailed out at the mkinitramfs stage,
>> couldn't find
>> /lib/modules/3.8.2 because it was named "3.8.2+".
>
>For this bisect run, can you do without the initramfs?  Just build the
>sata driver and the fs driver into the kernel.  You may want to drop
>makeit and just do the bare minimum, 'make bzImage && make modules &&
>make modules_install' or similar.
>
>The '+' means the kernel build system (using git) determined that there
>were changes to the source tree from the most recent tagged version.  If
>there weren't, it would just use the tag 3.8.2.  You can take a look at
>scripts/setlocalversion to see how it figures it out.
>
>hth,
>
>Jason.
Up, leg cramps, the wet ram ain't the only thing old.  Anyway did that, 
copied the vmlinix to /boot/vmlinuz-3.8.2+, update-grub, reboot, selected 
it, got invalid magic numbers.  So I'm back on 3.12.6.  But when I went to 
make sure that 3.8.2 worked, my script had screwed that up thinking it was 
building a real, from tarball 3.8.2.  But I have that tree untouched so it 
will re-install. Which I will start and go back to bed.

Next?

Thanks.

Cheers, Gene
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

The inclusion of any link does not imply endorsement of the site.
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.