lkml.org 
[lkml]   [2008]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: TSC not updating after resume: Bug or Feature?
    On Mon, 22 Dec 2008, Thomas Gleixner wrote:
    > On Mon, 22 Dec 2008, Ingo Molnar wrote:
    > > * Thomas Gleixner <tglx@linutronix.de> wrote:
    > >
    > > > > By the way, I don't know if it matters but the problema happened with
    > > > > in-kernel hibernation and also in out-of-tree TuxOnIce hibernation.
    > > > > Maybe this can help debugging the issue, I don't know.
    > > >
    > > > Hmm, does not ring a bell here. Can you please apply the patch below to
    > > > mainline and retest ?
    > >
    > > ... and he should send a dmesg after a suspend cycle, right?
    >
    > Yes :)
    >
    > I digged more in the bugzillas. Toralf added some debug to
    > __update_sched_clock():
    >
    > - max_clock = wrap_max(scd->clock, scd->tick_gtod + TICK_NSEC);
    > + max_clock = scd->tick_gtod + TICK_NSEC;
    > + if (scd->clock > max_clock)
    > + printk(KERN_INFO "%d %d\n", scd->clock, max_clock);
    >
    > The interesting output is:
    >
    > Dec 14 21:55:55 n22 Back to C!
    > Dec 14 21:55:55 n22 Extended CMOS year: 2000
    > Dec 14 21:55:55 n22 Force enabled HPET at resume
    > Dec 14 21:55:55 n22 212611283 77
    >
    > The 77 is totaly bogus and it's likely not just a truncation of the
    > 64bit value because (scd->clock > max_clock) evaluates to true. This
    > output is _AFTER_ timekeeping resume because the HPET force enable
    > message comes from timekeeping resume.

    Seems I'm talking to myself, but I think I finally decoded the
    mystery:

    resume()
    cpufreq_resume()
    tsc:time_cpufreq_notifier()
    set_cyc2ns_scale()
    sched_clock_idle_sleep_event()
    sched_clock_tick()
    ktime_get()
    hpet_read()

    This happens _BEFORE_ timekeeping has resumed, so hpet_read() returns
    nonsense and the timekeeping code uses the stale pre suspend
    xtime/clocksource reference values to calculate the time. So the gtod
    reference in sched_clock can result in total crap depending on the
    time when the suspend happened.

    Shaggys patch clamps sched_clock to the stale scd->clock value which
    might explain the further wreckage.

    The above sequence happens only for CPUs with a CPU frequency coupled
    TSC, so on newer machines with CPU frequency invariant TSC this does
    not happen.

    /me stomps off to find a box to confirm that.

    Thanks,

    tglx


    \
     
     \ /
      Last update: 2008-12-22 21:39    [W:0.022 / U:6.124 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site