Messages in this thread | | | Date | Sat, 29 Aug 2009 09:11:32 -0400 | Subject | Re: PROBLEM: oops | From | Eric Paris <> |
| |
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!
| |