Bug 105016 - APM is configured to assume that the CMOS clock is kept in UTC
APM is configured to assume that the CMOS clock is kept in UTC
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Depends On:
  Show dependency treegraph
Reported: 2003-09-24 13:40 EDT by Tim Mann
Modified: 2007-04-18 12:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:41:33 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim Mann 2003-09-24 13:40:00 EDT
Description of problem:

Default Red Hat kernels are configured with CONFIG_APM_RTC_IS_GMT=y.  This
causes the kernel APM support in arch/i386/kernel/apm.c to assume that the CMOS
clock is kept in UTC (aka GMT).  Whenever the kernel resumes from a suspended
state or receives an APM_UPDATE_TIME event, it calls set_time, which reads the
time from the CMOS clock and sets the system time to that value.  With
CONFIG_APM_RTC_IS_GMT=y, set_time unconditionally interprets the CMOS time as
UTC, even if the user has actually configured the CMOS clock to keep local time.
 Local time is the default for the CMOS clock when Red Hat is installed;
presumably this is for compatibility with Windows on dual boot machines.

Thus whenever the kernel gets one of these events on a machine with the CMOS
clock set to local time, it sets the system time to a value that is several
hours off.  For example, in the EDT time zone, which is 4 hours earlier than
UTC, the system time gets set back by 4 hours.

This bug seems pretty flagrant, but I imagine that it has gone unnoticed until
now because on most systems that support apm, the userspace apmd runs
immediately after resume and corrects the time.  I'm guessing that it's also the
case that most APM BIOSes seldom or never send APM_UPDATE_TIME events.  If one
of these does occur, the kernel apm.c resets the time (in check_events()) and
the userspace apmd does nothing, so the time remains wrong.

Version-Release number of selected component (if applicable):

Definitely exists in Red Hat kernels 2.4.20-8 and 2.4.20-20.{7,9}.  I haven't
checked it elsewhere.

How reproducible:

Set your CMOS clock to a non-GMT timezone.  Then (if you can), persuade your
system BIOS to send an APM_UPDATE_TIME event.  If you can't generate an
APM_UPDATE_TIME event, you should also be able to reproduce the problem by doing
an APM suspend/resume cycle but preventing apmd from resetting the system clock
after the resume.
Actual results:

You'll find that system time is now off by the number of hours that local time
differs from GMT.

Expected results:

System time set correctly.

Additional info:

One caveat: I don't know whether CONFIG_APM_RTC_IS_GMT=n will fix this bug with
introducing any other problems -- I haven't tested it.  You'll need to test it
and/or check with the maintainer of the kernel APM support to find out whether
there are any known bugs in the code that is enabled if you set this option.
Comment 1 David Olsson 2004-03-25 13:57:18 EST
This may explain my system's behavior.  I'm running Red Hat Enterprise
WS 3, fully up to date with Red Hat Network, on a Dell Inspiron 4000
(Red Hat certified).  Kernel version 2.4.21-9.0.1.EL.  timeconfig
reports America/New York, system clock not using UTC.  On startup,
initialization messages are logged with the correct time.  After
initialization, time is set back 5 hours.  hwclock -s restores correct
Comment 2 Bugzilla owner 2004-09-30 11:41:33 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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