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.
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 time.
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 persists. 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/