Subject: Bug#3261: apmd incorrectly sets clock for some systems.

From: Brian Mays <[email-masked]>
Date: Mon, 10 Jun 96 20:41:25 -0500

Package: apmd
Version: 2.4-1

Those APM users who have their system clocks set to GMT will notice an
annoying problem with apmd.  When resuming from suspension mode, the
daemon uses "clock -s" to reset the internal clock, which is incorrect
for clocks set to GMT (unless the user is in Greenwich).  The "-u"
flag must be used to inform the clock utility that the CMOS clock is
set to Universal Time.

As far as I know, the only thing in the Debian system that indicates
whether the CMOS clock is set to local time or GMT is the status of
the GMT variable in the /etc/init.d/boot file, which is set to "-u" if
Universal Time is used.  Perhaps there should be another way of
storing this information.

Here is one way to fix apmd for Debian systems:

--- apmd.c.orig	Sun Apr 21 16:49:56 1996
+++ apmd.c	Mon Jun 10 19:00:10 1996
@@ -348,7 +348,8 @@
 	 case APM_UPDATE_TIME:
 	 case APM_CRITICAL_RESUME:
 	    time( &then );
-	    system( "clock -s" );
+	    system( "if grep -q '^GMT=\"-u\"' /etc/init.d/boot; then"
+		    " clock -us; else clock -s; fi" );
 	    time( &now );
 	    check_power( 1, 0 );
 	    break;

--
Brian <[email-masked]>

---

From: [email-masked]
Date: Wed, 12 Jun 96 14:13 EDT

Brian> Package: apmd 
  Brian> Version: 2.4-1
  Brian> 
  Brian> Those APM users who have their system clocks set to GMT will notice
  Brian> an annoying problem with apmd.  When resuming from suspension mode,
  Brian> the daemon uses "clock -s" to reset the internal clock, which is
  Brian> incorrect for clocks set to GMT (unless the user is in Greenwich).
  Brian> The "-u" flag must be used to inform the clock utility that the CMOS
  Brian> clock is set to Universal Time.

Are you sure? My laptop has bios time set to GMT as well, and it behaves
differently! I just checked:

Jun 12 13:59:30 bird apmd[142]: Version 2.4 (APM BIOS 1.1, Linux driver 1.1)
Jun 12 13:59:30 bird apmd[142]: Charge: * * * (-1% 0:01)
Jun 12 14:03:49 bird apmd[142]: Resume after 00:01:43 (-1% 0:01)
Jun 12 14:04:53 bird in.rlogind[289]: connect from miles.econ.queensu.ca    

I booted the laptop at 13:59, called 'apm --suspend' around 14:01, pressed
the power button to get back from suspension --- and my clock is allright.
Note that my /etc/init.d/boot is set to preserve GMT.

# Set GMT="-u" if your system clock is set to GMT, and GMT=""
# if not.
GMT="-u"
# Set and adjust the CMOS clock.
clock -s $GMT
if [ ! -f /etc/adjtime ]
then
  echo "0.0 0 0.0" > /etc/adjtime
fi
clock -a $GMT              

I had checked the -S and -s behaviour when I released apmd-2.4. I had left
the machine suspended for several hours, and had no problem whatsoever. Could
it be something else?

--
Dirk Eddelb"uttel                             http://qed.econ.queensu.ca/~edd

---

From: Brian Mays <[email-masked]>
Date: Wed, 12 Jun 96 18:10:50 -0500

>>>>> "Dirk" == Dirk Eddelbuettel
<[email-masked]> writes:

    Brian> Those APM users who have their system clocks set to GMT
    Brian> will notice an annoying problem with apmd.  When resuming
    Brian> from suspension mode, the daemon uses "clock -s" to reset
    Brian> the internal clock, which is incorrect for clocks set to
    Brian> GMT (unless the user is in Greenwich).  The "-u" flag must
    Brian> be used to inform the clock utility that the CMOS clock is
    Brian> set to Universal Time.

    Dirk> Are you sure? My laptop has bios time set to GMT as well,
    Dirk> and it behaves differently!

    Dirk> Could it be something else?

I think that I know what's going on.  The APM in my computer is
somewhat screwed up.  When you suspend, the apmd daemon does a normal
suspend, and I am guessing that your internal clock continues to run
during the suspended state.  When you resume, the kernel's time does
not need to be reset since the internal clock has been running.
However, when I suspend my laptop, everything shuts down, including
the internal clock.  Thus, when I resume, the apmd daemon receives an
APM_CRITICAL_RESUME event.  This event resets the kernel's time, which
is still set to the time when the computer entered the suspended
state, by executing the clock program.

Thus, your computer has never encountered this problem because your
apmd daemon has never received an APM_UPDATE_TIME or
APM_CRITICAL_RESUME event.

--
Brian <[email-masked]>