[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070302072100.GB30634@elte.hu>
Date: Fri, 2 Mar 2007 08:21:00 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Jens Axboe <jens.axboe@...cle.com>, Pavel Machek <pavel@....cz>,
Adrian Bunk <bunk@...sta.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"Michael S. Tsirkin" <mst@...lanox.co.il>,
Thomas Gleixner <tglx@...utronix.de>, linux-pm@...ts.osdl.org,
Michal Piotrowski <michal.k.k.piotrowski@...il.com>,
Daniel Walker <dwalker@...sta.com>
Subject: Re: 2.6.21-rc1: known regressions (part 2)
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> But most likely, 9f4bd5dd is actually already bad, and what you are
> seeing is two *different* bugs that just have the same symptoms
> ("suspend doesn't work").
the situation is simpler than that: there is a /known/ bug, and i marked
the bugfix commit as 'good'. I never met such a multiple-bugs scenario
before and forgot that git-bisect could easily pick a tree without this
essential bugfix and would not be able to make a distinction between the
two types of badness.
I'll try what i've described in the previous mail: mark all bisection
points that do not include f3ccb06f as 'good' - thus 'merging' the
known-bad area with the first known-good commit, and thus eliminating it
from the bisection space.
(but it might also be useful to have a "git-bisect must-include" kind of
command that would allow this to be automated: mark a particular tree as
an essential component of the search space.)
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