Re: [Bug #17361] Random kmemcheck errors and kernel freeze on 2.6.36-rc*

[Rafael J. Wysocki]

On Monday, October 11, 2010, Christian Casteyde wrote:
> Hello

Hi,

> Well, I would like to find the real commit, but I don't know how to do that.
> I'm not so used to using other branches than Linus' one.
> 
> From the commit hash, how do I find:
> - the git tree I should use to bisect more?
> - the initial good and bad marks?
> And can I bisect only that branch on top of my current kernel source directory?

Yes, you can.  In this particular case the merge says that the series started
with commit "x86: Fix keeping track of AMD C1E" and ended with
"x86, xsave: Cleanup return codes in check_for_xstate()".

Now, you can do

$ git log --oneline v2.6.35.. | grep "x86: Fix keeping track of AMD C1E"

and you get this information:

e8c534e x86: Fix keeping track of AMD C1E

Similarly, this command

$ git log --oneline v2.6.35.. | grep "x86, xsave: Cleanup return codes in check_for_xstate()"

returns

d6d4d42 x86, xsave: Cleanup return codes in check_for_xstate()

so you probably need to bisect between commits d6d4d42 (presumably good)
and e8c534e (presumably bad).

However, it still is better to do "checkout d6d4d42" and see if that kernel is
good (and analogously for d6d4d42) to start with.

Thanks,
Rafael


> Le dimanche 10 octobre 2010 21:40:26, vous avez Ãcrit :
> > On Sunday, October 10, 2010, Christian Casteyde wrote:
> > > Still present with 2.6.37-rc7
> > > I think I managed to bisect it however:
> > > 
> > > 0f477dd0851bdcee82923da66a7fc4a44cb1bc3d is the first bad commit
> > 
> > This is a merge, so it most likely is not the real first bad commit.
> > 
> > Could you check the commits on the branch merged by it?
> > 
> > Rafael
> 
> 

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