Clock offsets during suspend/resume

Jan Lübbe jluebbe at
Fri Dec 12 16:27:31 CET 2008

On Fri, 2008-12-12 at 15:17 +0000, Andy Green wrote:
> Hash: SHA1
> Somebody in the thread at some point said:

> | According to the kernel log timestamps, some time is passing during
> | resume, just very little... Could this be some side effect of the full
> | cpu utilization? In any case, if we can't keep time correctly during
> | resume, the restore from hw clock should happen at the end of resuming.
> I would guess the effect could be mainly caused by sitting there
> scrolling the Glamo framebuffer, if you try it without console=tty0 on
> cmdline does it impact it?

Using 'echo 0 0 0 0 > /proc/sys/kernel/printk' it suspends and resumes a
lot faster and doesn't pick up any delay. Even after several cycles, the
sum is still below 1 second.

> | Of course it would be possible to work around it in userspace but that
> | still feels wrong. ;)
> Balaji, how do you feel about a delayed work in rtc driver that takes
> care of this?  If it isn't all down to Glamo then it can be a generic
> issue for this driver.

The weird thing is that even now, it still has an offset of 51 seconds
between system and hw clock. So it does not seem to restore from the hw
clock accessible via 'hwclock'... or does it remember the offset during


More information about the openmoko-kernel mailing list