Re: PROBLEM: oops

[Eric Paris <eparis@parisplace.org>]

On Fri, Aug 28, 2009 at 5:46 PM, Pawel Golaszewski<blues@gda.pl> wrote:
> On Thu, 27 Aug 2009, Peter Zijlstra wrote:
>> > > > # git log --format=oneline v2.6.27.13..v2.6.27.31 kernel/sched*
>> > > > 2b46f3769896dc04e1e49144d282e4655677105a wait: prevent exclusive waiter starvation
>> > > >
>> > > > Nothing changed anywhere near the code that is falling apart..
>> > > I have 2 machines with the same hardware and similar software. On
>> > > one .13 is stable - I will test it on the second one. Should be too.
>> > I've checked it - 2.6.27.13 is stable for me. Conclusion: there is
>> > something wrong between 2.6.27.13 and 2.6.27.31 What can I do about
>> > that? I'm not kernel-hacker...
>> Unless any of the memory debugging options yield a clue the best you can
>> do is a bisection I'm afraid.
>>
>> # git log --format=oneline v2.6.27.13..v2.6.27.31 | wc -l
>> 630
>
> Ok, I checked:
>
> 2.6.27.15 works fine
> 2.6.27.17 crashes (log was sent).
>
> What now?

Have you ever used git, and especially git-bisect?  That's what would
really help to run it down.  Try this operation.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-allstable.git
stable-tree
cd stable-tree
git bisect start
git bisect bad v2.6.27.17
git bisect good v2.6.27.15

(a)
[git will do some work and will leave you with a message that says
something like "Bisecting: 675 revisions left to test after this"]
build the kernel tree.
test your build.

if it works go back to the stable-tree directory and enter:
git bisect good

if that kernel fails enter:
git bisect bad

goto (a)

Eventually there will be no more revisions left to bisect, and you
will have been left with the first bad kernel revision in
"refs/bisect/bad".

Let us know what this patch is that broke it for you.

Thanks!