Re: PROBLEM: oops

From: Eric Paris
Date: Sat Aug 29 2009 - 09:11:39 EST

On Fri, Aug 28, 2009 at 5:46 PM, Pawel Golaszewski<blues@xxxxxx> 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 - is stable for me. Conclusion: there is
>> > something wrong between and 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:
> works fine
> 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://
cd stable-tree
git bisect start
git bisect bad v2.6.27.17
git bisect good v2.6.27.15

[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

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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at