linux-kernel - Re: HPET regression in 2.6.26 versus 2.6.25 -- revert for 2.6.26-rc1 failed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <798277.39371.qm@web82105.mail.mud.yahoo.com>
Date:	Thu, 14 Aug 2008 15:25:38 -0700 (PDT)
From:	David Witbrodt <dawitbro@...global.net>
To:	Yinghai Lu <yhlu.kernel@...il.com>
Cc:	Bill Fink <billfink@...dspring.com>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...e.hu>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>, netdev <netdev@...r.kernel.org>
Subject: Re: HPET regression in 2.6.26 versus 2.6.25 -- revert for 2.6.26-rc1 failed

> > 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!

--
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/