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.134 / U:0.224 seconds]
©2003-2011 Jasper Spaans. Advertise on this site