Re: [stable] Regression in 2.6.32.2: segfault on halt

["Holger Hoffstätte" <holger.hoffstaette@googlemail.com>]

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@gmx.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@gmx.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@intel.com>
Reported-by: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1257821402.5648.17.camel@marge.simson.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.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