Re: Git puzzle

From: Jason Cooper
Date: Sun Dec 29 2013 - 00:26:35 EST


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:// \
> >~/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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at