[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20071207114048.GB14598@elte.hu>
Date: Fri, 7 Dec 2007 12:40:48 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Bob Tracy <rct@...s.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, mcree@...on.net.nz,
linux-kernel@...r.kernel.org, rjw@...k.pl, rth@...ddle.net,
ink@...assic.park.msu.ru, linux-scsi@...r.kernel.org,
kay.sievers@...y.org, greg@...ah.com
Subject: Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
* Bob Tracy <rct@...s.com> wrote:
> > I'm struggling to see how any of those could have broken block
> > device mounting on alpha. Are you sure you bisected right?
>
> Based on what's in that commit, it *does* appear something went wrong
> with bisection. If the implicated commit is the next one in time
> sequence relative to
>
> # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap INLINE and name timeval_cmp better
>
> then the test of whether I bisected correctly is as simple as applying
> the commit and seeing if things break, because I'm running on the
> kernel corresponding to 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right
> now. Let me give that a try and I'll report back. Worst case, I'll
> have to start over and write off the past four days...
generally it's easier to just go "back in time" and re-try the last
known "good" and last-known "bad" commit IDs to establish that they are
indeed correctly identified. if they are not then step back one more in
the bisection log. No need to spend another 4 days on this, if most of
the bisection is OK. You can replay a corrected git bisection log
quickly, by doing:
git-bisect reset
git-bisect < bisect.log
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