lkml.org 
[lkml]   [2011]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    SubjectRe: 2.6.32.21 - uptime related crashes?
    From
    Date
    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;
    + */
    }

    /*


    \
     
     \ /
      Last update: 2011-07-21 14:29    [W:0.034 / U:0.400 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site