Re: Screwy clock after apm suspend

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

On Mon, Jan 10, 2005 at 11:57:59AM +0100, Pavel Machek wrote:
> > > > arch/i386/kernel/time.c, can you comment out
> > > > jiffies += sleep_length * HZ;
> > > 
> > > Worked like a charm.  I'm not seeing any time drift after your suggested 
> > > change.
> > 
> > AIUI, this also means that a machine's uptime does not include time
> > whilst suspended. This was the behaviour prior to 2.6.10 and seems to be
> > more desirable as it counts the time the machine is actually running,
> > not just time since boot. Is there a good reason why we can't go back to
> > this?
> 
> I think it means very wrong system clock in ACPI state.

So would implementing the equivalent of hwclock --hctosys keep both
ACPI & APM happy, but not include time suspended in uptime?

> Plus think something wanting timeout of five minutes, then suspend
> one minute after, machine sleeps for a hour.
> 
> With this approach, timeout should happen just after resume, with your
> approach, it would wait 4 more minutes.

It does depend on whether a timer wants a delay against the wall
clock or the rest of the system.  A process may be sleeping because
it's waiting for some other task to complete, or waiting for input
from the user. In these cases I claim time-whilst-hibernated should
not be counted.

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.

It also means that a group of timeouts that would normally occur a
large amount of time apart, will suddenly all expire the instant the
machine resumes, causing unexpected or undesirable behaviours, IMHO.

Bernard.