Bug 2396 - Suspend/resume cycle messes up TZ information
Suspend/resume cycle messes up TZ information
Status: CLOSED DUPLICATE of bug 6052
Product: Red Hat Linux
Classification: Retired
Component: apmd (Show other bugs)
6.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: David Lawrence
http://www.astro.rug.nl/~tim
:
: 2768 2783 3661 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-04-28 13:03 EDT by Pickering, Timothy
Modified: 2008-05-01 11:37 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-10-18 10:26:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pickering, Timothy 1999-04-28 13:03:47 EDT
The system clock on my laptop was set to UTC and my timezone
was set to Europe/Amsterdam (which is now UTC+2 and reported
as CEST).  After I upgraded to Redhat 6.0, the time was
reported correctly as UTC+2 upon the initial boot. However,
when I suspended the machine and then resumed, this changed
and the date command was reporting UTC instead of UTC+2.
Rebooting set the reported time back to UTC+2, but every
time i suspended, it went back 2 hours to UTC.  A workaround
that seems to do the trick for now is to set the system
clock to local time instead of UTC.  When I do this, date
reports a time 2 hrs fast immediately after resuming, but
within a few seconds it returns to reporting the correct
time.

I'm using the stock kernel and apmd that were installed by
redhat 6.0 which was installed as an upgrade over redhat
5.2.  i was previously using the stock redhat 5.2 apmd along
with a custom 2.2.1 kernel. The machine is a Toshiba Tecra
500CDT.
Comment 1 Jeff Johnson 1999-05-14 16:24:59 EDT
*** Bug 2783 has been marked as a duplicate of this bug. ***

My machine is a regular desktop, but I have power-saving
settings currently on (in my BIOS).  Whenver the machine
goes into suspend mode and comes back, the clock is set
forward.  I'm not sure what the magic formula is --
sometimes it seems to be set forward 20 minutes, sometimes 4
hours.

The only workaround I can figure out at the moment is to
disable energy-saving mode from the BIOS.

------- Additional Comments From yminsky@cs.cornell.edu  05/12/99 22:43 -------
Further information about the bug:  it appears that what happens is
that when the resume occurs, the timezone is ignored and the hwclock
value is directly set to the real clock value.  That, at least,
explains the cases I've run up against with the 4 hour move.  I'm not
sure about the 30-minute shift, but I can't replicate that one yet
anyway.

------- Additional Comments From notting@redhat.com  05/13/99 10:15 -------
Try grabbing the latest apmd package from Raw Hide; alternatively,
start apmd with the '-u' option if your system clock is
in UTC. Does that help?

------- Additional Comments From yminsky@cs.cornell.edu  05/13/99 13:37 -------
I switched over to storing my clock in regular time, not UTC (using
linuxconf) and the problem still persists, sort of.  Now, when I do
apm -s, it wakes up with the right time, but when I do apm -S, it
wakes up with the time set BACK by four hours.  This is with the
newest apm installed from the updates directory.  I haven't tried the
RawHide package.  The command line invocation for apmd (according to
ps) is:

    /usr/sbin/apmd -p 10 -w 5 -W

------- Additional Comments From yminsky@cs.cornell.edu  05/13/99 21:41 -------
One more addition:  When time is stored as UTC, then:
  return from apm -s sets time FORWARD four hours
  return from apm -S doesn't mess up the clock

when time is not stored as UTC, then:
  return from apm -s doesn't mess up clock
  return from apm -S sets clock four hours BACKWARDS

This would suggest that restoring from apm -s always assumes non-UTC,
and restoring from apm -S always assumes UTC.  But this is almost too
odd to believe.
Comment 2 Jeff Johnson 1999-05-14 16:25:59 EDT
*** Bug 2768 has been marked as a duplicate of this bug. ***

I'm using an HP Omnibook 800CT. when I boot up RedHat 6.0,
everything goes fine until the screen clears and the
initial login prompt appears....in order to get any
interaction, I must suspend the machine, then unsuspend it.
After that, everything works fine.

I also noticed the same problem in the installation - when
the install finishes with the RPMs, I must
suspend/unsuspend in order to be able to continue
interactive with the system. I'm assuming it's a problem
with the APM, since suspend/unsuspend fixes it...
Comment 3 Yaron Minsky 1999-05-17 12:59:59 EDT
Having put in the latest version of apmd, the system works well when
the clock is stored in UTC, but jumps backwards in time when the clock
is stored in local time.
Comment 4 David Lawrence 1999-06-14 19:56:59 EDT
An apmd update has been placed on the updates.redhat.com ftp site to
fix some of these issues. Please obtain and install the update and see
if this solves your problem. If not, please reopen the bug.
Comment 5 Jeff Johnson 1999-06-23 10:36:59 EDT
*** Bug 3661 has been marked as a duplicate of this bug. ***

This might reopen Bug #2396

I have installed the latest apmd package:
<68> rpm -qa|grep apm
apmd-3.0beta5-8

My timezone is:
/etc/localtime -> ../usr/share/zoneinfo/Europe/Copenhagen

My hwclock is set to localtime.

Running apm -s (or -S) puts the machine time two hours ahead
after wake up. No changes are made to the timezone.

I see the same problem on some of my machines, which happen
to enter sleep mode after a while. I wonder why some of them
enter sleep mode, while others do not, since I have followed
the same installation procedures and all the motherboards
respond to apm.
Is there any other way to control the suspend mode? Is that
buggy as well?
Comment 6 mcb 1999-09-22 13:52:59 EDT
I also see this clock problem, even though apmd is turned off.
Does something activate apm even on desktop machines when everything
claims apm is unused?  At this point I'm inclined to believe that
something else is the culprit.  Also makes more sense that two
separate packages would have different expectations of the hardware
clock being UTC or not, than that one package had split opinions.
-- Mark Beutnagel -- mcb@research.att.com
Comment 7 Bill Nottingham 1999-10-18 10:26:59 EDT
*** This bug has been marked as a duplicate of 6052 ***
Comment 8 rjb 1999-10-26 14:42:59 EDT
Bug 6931 might also be a duplicate. I always see curious messages
from apmd immediately before xntpd reports that time is screwed and
exits. E.g.:

Oct 22 14:08:13 gibbs apmd[100]: Resume after 00:4294967267:4294967242
(-1% unknown)
Oct 22 14:08:14 gibbs apmd[100]: Resume after 00:00:00 (-1% unknown)
Oct 22 14:14:11 gibbs xntpd[403]: time error 1799.996840 is way too
large (set clock manually)

Note You need to log in before you can comment on or make changes to this bug.