lkml.org 
[lkml]   [2005]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: rc6 keeps hanging and blanking displays where rc4-mm1 works fine.


On Mon, 15 Aug 2005, Helge Hafting wrote:
>
> Ok, I have downlaoded git and started the first compile.
> Git will tell when the correct point is found (assuming I
> do the "git bisect bad/good" right), by itself?

Yes. You should see

Bisecting: xxx revisions left to test after this

and the "xxx" should hopefully decrease by half during each round. And t
the end of it, you should get

<sha1> is first bad commit

followed by the actual patch that caused the problem.

> Is there any way to make git tell exactly where between rc4 and rc5
> each kernel is, so I can name the bzimages accordingly?

You'd have to use the raw commit names, since these things don't have any
symbolic names. You can get that by just doing

cat .git/HEAD

which will give you a 40-character hex string (representing the 160-bit
SHA1 of the top commit). Not very readable, but it's unique, and if you
report that hex string to other git users, they can trivially recreate the
tree you have.

> It takes some time to trigger the bug, so I could possibly end up with
> a falsely ok kernel. Is there a simple way to restart the search from
> that point, or will I have to start over with rc4 and rc5 and say
> git bisect good/bad until I reach the point of mistake?

If you remember/save the good/bad commit ID's, you can restart the whole
process and just feed the correct state for the ID's:

git bisect start
git bisect bad v2.6.13-rc5
git bisect good v2.6.13-rc4
.. here bisect will start narrowing things down ..
git bisect bad <sha1 of known bad>
git bisect good <sha1 of known good>
..

ie you can always feed an arbitrary number of known good/bad points by
naming them by their SHA1 ID (or their symbolic name, as in the
v2.6.13-rcX releases).

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.125 / U:2.852 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site