From: David Witbrodt <dawitbro@sbcglobal•net>
To: Yinghai Lu <yhlu.kernel@gmail•com>
Cc: Bill Fink <billfink@mindspring•com>,
linux-kernel@vger•kernel.org, Ingo Molnar <mingo@elte•hu>,
"Paul E. McKenney" <paulmck@linux•vnet.ibm.com>,
Peter Zijlstra <peterz@infradead•org>,
Thomas Gleixner <tglx@linutronix•de>,
"H. Peter Anvin" <hpa@zytor•com>, netdev <netdev@vger•kernel.org>
Subject: Re: HPET regression in 2.6.26 versus 2.6.25 -- revert for 2.6.26-rc1 failed
Date: Thu, 14 Aug 2008 15:25:38 -0700 (PDT) [thread overview]
Message-ID: <798277.39371.qm@web82105.mail.mud.yahoo.com> (raw)
> > I do not know how to bisect with your patch if I have a
> > "bad" but no "good" to start with. Can you explain how
> > I should proceed when I _do_ get home? (I can just enabled
> > those config options and try the patch again, but I am
> > confused about the bisect you are asking me to perform.)
> >
> just like the old way doing git-bisect, but before compiling, apply
> the batch, and before git-bisect good or bad, revert the patch.
Let's say I start with this:
1. 'git checkout v2.6.27-rc3'
2. [apply patch]
3. build kernel + reboot
If the kernel locks up, you want me to:
4. [un-apply the patch]
5. 'git bisect start'
6. 'git bisect bad'
Of course, we both hope that the kernel will NOT lock up,
but let's say it does. My confusion is the what step to take
next. To use 'git bisect' I have to select the next kernel
version manually until I find a "good" and "bad" version...
then git can automatically do its bisecting process.
I assume you would want me to choose a previous kernel
version, like "v2.6.27-rc2". If I keep getting "bad"
kernels, do you want me to just keep using earlier
versions... until the patch will no longer apply?
I must have misunderstood the git man pages: I thought
that the purpose of bisecting was to find a commit that
caused a problem, which presumes that you already know
a version of the kernel which works and a version which
does not work. Have I misunderstood?
Dave W.
PS: My apologies if I seem obtuse. Before this LKML
thread, I had only used git once -- and only to do
a checkout... no higher functionality like bisecting,
branching, merging, etc. I am learning quickly, but
frankly I am baffled about how to do what you are
asking!
next reply other threads:[~2008-08-14 22:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-14 22:25 David Witbrodt [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-08-14 18:11 HPET regression in 2.6.26 versus 2.6.25 -- revert for 2.6.26-rc1 failed David Witbrodt
2008-08-14 18:29 ` Yinghai Lu
2008-08-14 12:03 David Witbrodt
2008-08-14 17:39 ` Yinghai Lu
2008-08-13 15:41 David Witbrodt
2008-08-14 10:04 ` Bill Fink
2008-08-14 10:36 ` Yinghai Lu
2008-08-15 7:17 ` Bill Fink
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=798277.39371.qm@web82105.mail.mud.yahoo.com \
--to=dawitbro@sbcglobal$(echo .)net \
--cc=billfink@mindspring$(echo .)com \
--cc=hpa@zytor$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=mingo@elte$(echo .)hu \
--cc=netdev@vger$(echo .)kernel.org \
--cc=paulmck@linux$(echo .)vnet.ibm.com \
--cc=peterz@infradead$(echo .)org \
--cc=tglx@linutronix$(echo .)de \
--cc=yhlu.kernel@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox