Messages in this thread Patch in this message | | | Subject | Re: 2.6.32.21 - uptime related crashes? | From | Peter Zijlstra <> | Date | Thu, 21 Jul 2011 14:24:58 +0200 |
| |
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; + */ } /*
| |