🚀 go-pugleaf

Michael Dwyer wrote:
> Yeah, setting the clock is one thing...  its the whole
> getting-the-clock-to-stop-stopping thing that hurts.  I have an
> idea, though:  Is is possible that you are using some of the APM
> stuff?  When APM goes into effect, the harware (CMOS) clock still
> runs, but the linux software clock, of course, can't run.  This
> sounds like the problem.  To test it, try this:
> 
> clock -r   # Read the CMOS clock and print it.
> date       # Read the software clock and print it.

Right after rebooting I get this:

# clock -r
Thu Apr 13 23:48:28 2000 -0.117809 sec
# date
Thu Apr 13 23:48:31 MDT 2000

Now I let the screensaver take over, and about 12 minutes later I get:

#clock -r
Fri Apr 14 00:13:31 2000 -0.711014
# date
Thu Apr 13 18:13:35 MDT 2000

> 
> If I am close, then the CMOS clock should always be correct, and
> the software one is slipping.

Well not only is the SW clock slipping, it is going back in time! So it
appears that it may be the APM. Is it possible to turn that off?


> 
> The problem is that I don't know where to fix this problem...

Well, rebooting works, but that is rather drastic.

> 
> If nothing else, you might be able to call clock -s  every time
> a screen saver quits.

Well that is better than rebooting.

> 
> You sure do get the interesting problems... :)
> 

Gee thanks. It's pretty bad when I can get a reputation for interesting
problems when I don't want them in the first place.  :)

Xylen