[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080321195813.GC16179@elte.hu>
Date: Fri, 21 Mar 2008 20:58:13 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Valdis.Kletnieks@...edu
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
Subject: Re: 2.6.25-rc3-mm1 - BUG at system shutdown time
* Valdis.Kletnieks@...edu <Valdis.Kletnieks@...edu> wrote:
> git-bisect good ad42b55d36238ebb9fa4d7a538ef691a76397c46
> # good: [56b412e63863ea82a5720315076c7dbd1d9888cd] x86: change x86 to use generic find_next_bit
> git-bisect good 56b412e63863ea82a5720315076c7dbd1d9888cd
> # good: [42de918f25dc9a49fb9688e22c2a3f2b156cc1bf] x86: prevent unconditional writes to DebugCtl MSR
> git-bisect good 42de918f25dc9a49fb9688e22c2a3f2b156cc1bf
>
> At this point, 'git bisect visualize' shows 9 commits left to bisect
> through, and all are dated 03/10 or later. However, since 25-rc3-mm1
> had the problem, it had to be something in-tree as of 03/05.
>
> Is it possible that the problem code was in the git-x86 tree when
> Andrew pulled for -rc3-mm1 and -rc5-mm1, but had been reverted by the
> time I grabbed the tree, so the /x86/base' was in fact *good* by that
> point?
no, we frequently regenerate the x86.git tree so the dates have little
relevance. If for any particular pull, x86/base is good and x86/latest
is bad, then the bug is somewhere in those 200-300 patches inbetween.
They are lined up linearly so should be perfectly bisectable.
Ingo
--
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/
Powered by blists - more mailing lists