On Sun, 21 Dec 2008, Thomas Gleixner wrote:
quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/