Re: Screwy clock after apm suspend

[Bernard Blackham <bernard@blackham.com.au>]

On Tue, Jan 11, 2005 at 01:14:26AM +0100, Pavel Machek wrote:
> > So would implementing the equivalent of hwclock --hctosys keep both
> > ACPI & APM happy, but not include time suspended in uptime?
> 
> I think that hwclock --hctosys is not quite straightforward operation
> -- it needs to know if your CMOS clock are in local timezone or GMT,
> or something like that, IIRC.
> 
> But this might work: compute difference between system and cmos time
> before suspend, and use that info to restore time after suspend.

Forgive my ignorance, but isn't this exactly what's done already?

Looking harder, in arch/i386/kernel/apm.c the system time is also
saved and restored in a very similar way to timer_suspend/resume.
Would this account for the time drift in APM mode? (sleep time being
accounted for twice?)

> > Hibernating shouldn't be noticeable to the system. For example, a
> > popup window that came up an instant prior to suspending which is
> > normally on the screen for several seconds would vanish instantly
> > upon resuming without the user ever seeing it.
> 
> I disagree here.
> 
> If I do cli(); sleep(5 hours); sti();, system should survive that. If
> you do cli(); sleep(5 hours); sti() but fail to compensate for lost
> ticks, all sorts of funny things might happen if you are comunicating
> with someone who did not sleep.

Then shouldn't it be fixed to compensate?

By including suspend time in jiffies, there becomes absolutely no
way for a kernel or userspace thread to measure actual usable system
time. At least if suspend time is not counted, they can use jiffies
or xtime depending on what they want to do. Making them one and the
same gives them no choice.

Bernard.