[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B2E264E.4090805@googlemail.com>
Date: Sun, 20 Dec 2009 14:27:42 +0100
From: Holger Hoffstätte
<holger.hoffstaette@...glemail.com>
To: Willy Tarreau <w@....eu>
CC: linux-kernel@...r.kernel.org, stable@...r.kernel.org,
Mike Galbraith <efault@....de>
Subject: Re: [stable] Regression in 2.6.32.2: segfault on halt
Willy Tarreau wrote:
> Hi Holger,
>
> On Sun, Dec 20, 2009 at 12:55:50PM +0100, Holger Hoffstätte wrote:
>> Willy Tarreau wrote:
>>> On Sat, Dec 19, 2009 at 04:10:49PM +0100, Holger Hoffstaette wrote:
>>>> After updating to 2.6.32.2 last night (using same config from .32.1) I
>>>> noticed that "halt" now trips during shutdown and won't power the
>>>> machine down any longer. This happens reproducibly on two completely
>>>> different machines, so it looks like a generic problem and regression,
>>>> since it did not happen in .32.1. Note that "reboot" works as expected -
>>>> only "halt" crashes.
>>> I have it working fine here. So your config helps to reproduce the issue.
>>> Care to post it ?
>> Attached, if it matters. However I managed to find some time with a spare
>> machine and always wanted to try bisect, so that's what I did - apparently
>> successfully:
>>
>> root>git bisect bad
>> 37ed2d7007a65874850f3e357c095806c3756330 is the first bad commit
>> commit 37ed2d7007a65874850f3e357c095806c3756330
>> Author: Mike Galbraith <efault@....de>
>> Date: Wed Nov 4 17:53:50 2009 +0100
>>
>> sched: Rate-limit newidle
>
> Interesting, because I saw this one too while digging the patch preview
> for the word "migration" which appeared in your trace. But these changes
> did not look suspicious (no obvious invalid pointer dereference for
> instance).
>
> CCing Mike who may have an idea.
Took me some time (still learning git - I usually use hg) but I just
managed to fix it by reverting not the bisected revision (won't compile
any longer), but the follow-up "cleanup & fix":
>From 35c1ee3e78766d5666f418af638def9c67e63ecb Mon Sep 17 00:00:00 2001
From: Mike Galbraith <efault@....de>
Date: Tue, 10 Nov 2009 03:50:02 +0100
Subject: [PATCH] sched: Fix and clean up rate-limit newidle code
commit eae0c9dfb534cb3449888b9601228efa6480fdb5 upstream.
Commit 1b9508f, "Rate-limit newidle" has been confirmed to fix
the netperf UDP loopback regression reported by Alex Shi.
This is a cleanup and a fix:
- moved to a more out of the way spot
- fix to ensure that balancing doesn't try to balance
runqueues which haven't gone online yet, which can
mess up CPU enumeration during boot.
Reported-by: Alex Shi <alex.shi@...el.com>
Reported-by: Zhang, Yanmin <yanmin_zhang@...ux.intel.com>
Signed-off-by: Mike Galbraith <efault@....de>
Acked-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>
LKML-Reference: <1257821402.5648.17.camel@...ge.simson.net>
Signed-off-by: Ingo Molnar <mingo@...e.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@...e.de>
aka:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.32.y.git;a=commit;h=35c1ee3e78766d5666f418af638def9c67e63ecb
Reverting this from a clean 32.2 tree results in a kernel with newidle
fix, but still working halt/reboot. The only difference between this and
the bisected one is the additional change in cpumask handling.
That was more fun than expected :)
Holger
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists