Jamie Lokier <lkd@tantalophile.demon.co.uk> writes:
> On Mon, Oct 05, 1998 at 07:54:18PM +0200, Marco d'Itri wrote:
> > I have an AND K6-2 that sleeps every night until someone will press a
> > key on the console. While sleeping the clock does not advance.
> > It shows this problem with and without APM enabled in the BIOS and
> > with and without APM enabled in the kernel.
>
> I have a K6 that sleeps many times a day, and I don't have your problem.
>
> What I do is run apmd, that logs messages about sleep and wakeup times,
> and it wouldn't surprise me if it is also updating the clock after a
> wakeup.
>
> APM is also enabled in the kernel, of course.
>
> Ah, in the man page apmd(8):
>
> When a critical resume occurs, apmd will make a feable attempt to
> reset the clock.
>
> It is a pretty feeble attempt, too. The new system clock is restored
> from the CMOS clock. This tends to be a few minutes behind the kernel
> clock, unfortunately. Even when it isn't, apmd doesn't get it exactly
> right (it's a few seconds off). It will solve the
> going-to-sleep-at-night problem though.
>
> Unfortunately the system clock and the CMOS clock tend to be a few
> minutes apart on my machine, and all the programs which synchronise time
> with the net don't keep the CMOS clock and kernel clocks synchronised
> (except xntpd, but I haven't worked out how to run xntpd all the time to
> keep kernel and CMOS clocks synchronised while (a) doing it's thing over
> a modem when the modem is connected for only a few minutes occasionally;
> (b) not preventing the PPP idle timeout).
>
> clock -wu doesn't help much, because that doesn't account for drift later.
On resume (assuming the BIOS tell us) the APM driver in the kernel sets
the system time to the same offset from the CMOS clock that it had before
the suspend. This is about as good as you can get as we have no other
clock available that has been running while we slept.
One proviso, this only works if the BIOS notified us that is was
suspending ...
(APM BIOS bugs are many and varied :-)
Cheers,
Stephen
-- Stephen Rothwell Stephen.Rothwell@canb.auug.org.au http://www.canb.auug.org.au/~sfr/- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/