Re: 2.6.32.21 - uptime related crashes?

[Peter Zijlstra <peterz@infradead.org>]

On Thu, 2011-07-21 at 09:22 +0200, Ingo Molnar wrote:
> 
> Ping, what's going on with this bug? Systems are crashing so we need 
> a quick fix ASAP ... 

Something as simple as the below ought to cure things for now. Once we
get __cycles_2_ns() fixed up we can enable it again.

(patch against -tip, .32 code is different but equally simple to fix)

---
Subject: x86, intel: Don't mark sched_clock() as stable

Because the x86 sched_clock() implementation wraps at 54 bits and the
scheduler code assumes it wraps at the full 64bits we can get into
trouble after 208 days (~7 months) of uptime. 

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 arch/x86/kernel/cpu/intel.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index ed6086e..c8dc48b 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -91,8 +91,15 @@ static void __cpuinit early_init_intel(struct cpuinfo_x86 *c)
 	if (c->x86_power & (1 << 8)) {
 		set_cpu_cap(c, X86_FEATURE_CONSTANT_TSC);
 		set_cpu_cap(c, X86_FEATURE_NONSTOP_TSC);
+		/*
+		 * Unfortunately our __cycles_2_ns() implementation makes
+		 * the raw sched_clock() interface wrap at 54-bits, which
+		 * makes it unsuitable for direct use, so disable this
+		 * for now.
+		 *
 		if (!check_tsc_unstable())
 			sched_clock_stable = 1;
+		 */
 	}
 
 	/*