Messages in this thread | | | Date | Sun, 21 Dec 2008 20:43:56 +0100 (CET) | From | Thomas Gleixner <> | Subject | Re: TSC not updating after resume: Bug or Feature? |
| |
On Sun, 21 Dec 2008, Thomas Gleixner wrote: > On Thu, 18 Dec 2008, Rafael J. Wysocki wrote: > > > 5b7dba4: sched_clock: prevent scd->clock from moving backwards > > > > > > and the bug triggered by hibernation fixed instead. > > Hmm. Depending on the hibernation sleep time we can end up with a > pretty long delta between the pre suspend and the post resume call to > __update_sched_clock(). > > I have the feeling that sched_clock looks into stale values after > resume and the first call to __update_sched_clock() trips over the > stale scd->clock value. Shaggy's patch brings scd->clock into the mix > and that might cause the whole machinery to blow up on resume. > > Also we need to investigate whether sched_clock is referencing gtod > values _before_ timekeeping is resume.
I checked the two bugzillas (12149 & 12155) and both reporters have hpet=force on the command line.
One of the reporters said: "If I de-select CONFIG_HPET_TIMER then the issue went away ..."
It looks like this was not further investigated. Is this problem reproducible on other systems as well ?
Thanks,
tglx
| |