Re: Simple script that locks up my box with recent kernels

Linus Torvalds
2006-10-07T03:11:40Z

On Sat, 7 Oct 2006, Jesper Juhl wrote:
>
> Which has worked great in the past, but with recent kernels it has
> been a sure way to cause a complete lockup within 1 hour :-(

Reliable lock-ups (and "within 1 hour" is quite quick too) are actually
great.

> 2.6.17.13 .
> The first kernel where I know for sure it caused lockups is
> 2.6.18-git15 . I've also tested 2.6.18-git16, 2.6.18-git21 and
> 2.6.19-rc1-git2 and those 3 also lock up solid.

Can I bother you to just bisect it?

Even if you decide that it's too painful to bisect to the very end, "git
bisect" will give great results after just as few reboots as four or five,
and hopefully narrow down the thing a _lot_.

So, for example, while my git tree doesn't contain the stable release
numbers, you can trivially just get my tree, and then point "git fetch" at
the stable git tree and get v2.6.17.13 that way.

Then you can do just

git bisect start
git bisect good v2.6.17.13
git bisect bad $(cat patch-2.6.18-git15.id)

and off you go - it will pick a half-way point for you to test, and then
if that one was good, you just say "git bisect good", and it will pick the
next one..

(that "patch-2.6.18-git15.id" thing is from kernel.org - it's how you can
get the exact git state of any particular snapshot, even if it's not
tagged in any real tree - that particular one seems to have SHA1 ID
1bdfd554be94def718323659173517c5d4a69d25..)

"git bisect" really does kick ass. Don't worry if it says "10374 commits
to test after this" - because it does a binary search, it basically
cuts the commits to test in half each time, and so if you do just five
bisections, you'll have cut down the 10,000 commits to just a few hundred.
At that point, maybe we even have a clue, or we might ask you to test a
few more times to narrow things down even more.

Linus