linux-kernel - Re: Git puzzle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20131229052556.GM19878@titan.lakedaemon.net>
Date:	Sun, 29 Dec 2013 00:25:56 -0500
From:	Jason Cooper <jason@...edaemon.net>
To:	Gene Heskett <gheskett@...v.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Git puzzle

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/