[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.0908271121100.16876@fgnss.gnfx.tqn.cy>
Date: Thu, 27 Aug 2009 11:24:27 +0200 (CEST)
From: Pawel Golaszewski <blues@....pl>
To: Peter Zijlstra <peterz@...radead.org>
cc: linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
Dhaval Giani <dhaval.giani@...il.com>
Subject: Re: PROBLEM: oops
On Thu, 27 Aug 2009, Peter Zijlstra 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
Which options?
> 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.
I will try it too...
--
pozdr. Paweł Gołaszewski jid:blues<at>jabber<dot>gda<dot>pl
--------------------------------------------------------------------------
If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby
Pro-Logic Surround Sound with Bass Boost and all the music is free.
Powered by blists - more mailing lists