Re: PROBLEM: oops

[Peter Zijlstra <peterz@infradead.org>]

On Thu, 2009-08-27 at 09:58 +0200, Paweł Gołaszewski wrote:
> On Wed, 26 Aug 2009, Pawel Golaszewski wrote:
> > > > > > > could you try to reproduce without that?
> > > > > > > 
> > > > > > > CONFIG_GROUP_SCHED=n
> > > > > > I'll try. 
> > > > It seems that problem still exists - system has crashed too. From 
> > > > netconsole: Any ideas? Last kernel I was using is 2.6.27.13 - works 
> > > > fine. None between 13 and 31 tested...
> > > # 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

Which should be something like 10 kernel builds to find a patch, and
then one more with just that one reverted.