Hide Forgot
This bug seems to be reported different times and it is still present in Red Hat 6.1. Past references are bugs #2396, #3661, #3744. Note that bugs #2396 and #3661 are declared RESOLVED. Please, REOPEN them. I'm running the following rpms (coming with a standard Red Hat 6.1): kernel-2.2.12-20 apmd-3.0beta9-3 timeconfig-3.0-5 linuxconf-1.16r3.2-2 My time zone is CEST (Europe/Copenhagen). The problem: if the hwclock is set to local time and the machine goes into power saving mode (whether it's BIOS or apm doesn't really matter), my system time is moved two hours ahead (this is the difference in time between UTC and CEST, so it acts as if the hwclock, our only reference when resuming from power save, was set to UTC). More than that, 'linuxconf' and 'timeconfig/setclock' seem to be incoherent when writing '/etc/sysconfig/clock' and setting the hwclock. It seems we are facing two bugs here. First: the system (kernel??, apm?? - Bug 3744, comment 08/30/99 10:01 mention this) doesn't check whether the hwclock is UTC or 'local time' when resuming from power save. It always assume UTC! Second: we assume our hwclock must be UTC. 'linuxconf' then writes the following '/etc/sysconfig/clock' configuration. # cat /etc/sysconfig/clock ZONE="Europe/Copenhagen" UTC="yes" ARC=false The value "yes" for variable UTC is not understood by '/usr/sbin/setclock'. So if you use 'setclock' with such a configuration file, you end up setting your hwclock as 'local time'! This will obviously mess the clock next time you go power save (e.g. try 'apm -S' as root). Note that 'timeconfig' writes this '/etc/sysconfig/clock' instead (good for 'setclock'): # cat /etc/sysconfig/clock ZONE="Europe/Copenhagen" UTC=true ARC=false so the various clock commands seem to disagree on how to set the hwclock! In my opinion, the system should handle hwclock both as UTC or local time with no problems (i.e. check correctly if the hwclock is UTC or not), and the various time configuration tools should agree on how to handle the two cases
*** Bug 2396 has been marked as a duplicate of this bug. *** 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. ------- Additional Comments From jbj 05/14/99 16:24 ------- *** 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.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 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.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.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. ------- Additional Comments From jbj 05/14/99 16:25 ------- *** 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... ------- Additional Comments From yminsky.edu 05/17/99 12:59 ------- 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. ------- Additional Comments From dkl 06/14/99 19:56 ------- 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. ------- Additional Comments From jbj 06/23/99 10:36 ------- *** 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? ------- Additional Comments From mcb.com 09/22/99 13:52 ------- 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.com
*** Bug 3744 has been marked as a duplicate of this bug. *** I realize that there was already an errata notice about APMd losing time. I syncronized my clock using NTP. I then left the computer for a while. I came back, and the clock was off by 30 minutes. [root@slacker pietb]# /usr/sbin/ntpdate tock.cs.unlv.edu 26 Jun 09:44:38 ntpdate[1108]: step time server 131.216.18.4 offset -76.758548 sec [root@slacker pietb]# /usr/sbin/ntpdate tock.cs.unlv.edu 26 Jun 09:44:41 ntpdate[1109]: adjust time server 131.216.18.4 offset 0.006088 sec [root@slacker pietb]# /usr/sbin/ntpdate tock.cs.unlv.edu 26 Jun 09:44:44 ntpdate[1110]: adjust time server 131.216.18.4 offset 0.003191 sec [root@slacker pietb]# date Sat Jun 26 09:49:10 EDT 1999 [went out to breakfast, came back] [root@slacker pietb]# /usr/sbin/ntpdate tock.cs.unlv.edu 26 Jun 12:11:52 ntpdate[1198]: step time server 131.216.18.4 offset 2040.635256 sec [root@slacker pietb]# [root@slacker rc3.d]# rpm -q apmd apmd-3.0beta5-8 Here's /var/log/messages Jun 26 09:02:33 slacker syslogd 1.3-3: restart. Jun 26 06:46:09 slacker apmd[128]: Resume after 4294967292:4294967295:4294967239 (-1% unknown) Jun 26 07:30:23 slacker apmd[128]: Resume after 00:44:14 (-1% unknown) Jun 26 11:30:23 slacker apmd[128]: Resume after 04:00:00 (-1% unknown) Jun 26 11:31:08 slacker PAM_pwdb[1171]: (su) session opened for user root by pietb(uid=500) I haven't verified that the clock isn't busted, but I don't get the time warp in Windows. ------- Additional Comments From jbj 06/26/99 22:38 ------- You can't expect xntpd -- a program that requires a running cpu to keep track of time -- if you run another program apmd that stops the cpu from running. You don't get the time warp in Windows because Windows just reads the battery backed up hardware clock and uses that as the system time. You also don't get a system time on windows that is usually within 10 ms of a primary reference clock on windows either; that's the funxtion that xntpd performs that requires a running cpu. ------- Additional Comments From pietb 06/27/99 22:50 ------- Umm. Perhaps you misunderstood. After screen blanks out from APMd, I lose an half an hour! More than once!! With striking regularity! The ntpdate shows how much drift is being caused by the apm daemon. The example I showed had 2000 seconds. THAT'S SIGNIFICANT! The clock isn't busted, I just spent hours in 95, and no time drift. it apmd. I know it. I'm re-opening the bug. ------- Additional Comments From pietb 06/27/99 22:51 ------- Umm. Perhaps you misunderstood. After screen blanks out from APMd, I lose an half an hour! More than once!! With striking regularity! The ntpdate shows how much drift is being caused by the apm daemon. The example I showed had 2000 seconds. THAT'S SIGNIFICANT! The clock isn't busted, I just spent hours in 95, and no time drift. it apmd. I know it. I'm re-oThe first issue is a kernel issue - it's most likely compiled with: #define CONFIG_APM_RTC_IS_GMT 1 As for the second, linuxconf is broken. A workaround is in timeconfig-3.0.1-1, which will be in the next Raw Hide release.pening the bug. ------- Additional Comments From yminsky.edu 08/28/99 12:53 ------- I have similar APMD problems, and I'm not running xntpd. Here's what I've found. Sometimes, when my laptop wakes up, the time is set wrong. Not reliably, tough. I store my time in real time (not UTC), and there seems to be some problems with that. The following is the output of repeated executions of "date" when I put the machine to sleep and then wake it up. snapdragon: init.d $ while true; sleep 1; do date; done Sat Aug 28 12:46:38 PM EDT Sat Aug 28 12:46:39 PM EDT Sat Aug 28 12:46:40 PM EDT Sat Aug 28 12:46:41 PM EDT Sat Aug 28 12:46:42 PM EDT Sat Aug 28 12:46:43 PM EDT Sat Aug 28 12:46:44 PM EDT Sat Aug 28 8:47:16 AM EDT Sat Aug 28 8:47:18 AM EDT Sat Aug 28 12:47:18 PM EDT Sat Aug 28 12:47:19 PM EDT In other words, when it wakes up, it temporarily restores the time as if it was stored in UTC, and then immediatly (within 2 seconds) switches it back. THis is the "good" outcome, since the date finally reaches the right value. But it's still weird. And sometimes, I'm not sure why or when, I leave it for a while and find it set on the wrong time, that is, set to the time it would be if I stored the date in UTC. This is really a bit weird. I fixed a similar problem on my desktop some time ago by changing /etc/sysconfig/clock so that instead of reading: UTC="yes" ARC=false it read: UTC=true ARC=false That fixed some problems, but I did the same thing on my laptop to no avail. I'm running Linux on a Dell Solo 2500. (lovely machine, btw.;) ------- Additional Comments From jbj 08/28/99 17:47 ------- Running APM and xntp makes no sense since the xntpd requires periodic time stamps every 1-60 seconds while apmd turns off the cpu. Run ntpdate every 5 mins from cron to synchronize with a server if you wish to work around the problem. ------- Additional Comments From yminsky.edu 08/29/99 10:28 ------- I'm not sure if the above response from jbj@redhat is to my post, but let me reiterate: I am NOT using xntpd. I find similar problems even so. So whether or not it's a good idea to use xntpd on a laptop is irrelevant. ------- Additional Comments From 08/30/99 10:01 ------- After reading recent comments, I went in and recompiled my kernel -- I set the setting that time is local instead of UTC (it's in the Power Management settings section), and now every time the apm daemon launches, I don't lose 4 hours anymore. That was it, you see. When apm started, I would be losing around 14,400 seconds -- about 4 hours. It never made much sense to me as to why I was losing about the same amount of time with each apm suspend. The apm daemon *should* be able to figure out the difference between which mode the system is in, without requiring a recompilation of the kernel.
Get the apmd package from Raw Hide (3.0beta9-4) - and make sure to add -u to ADDPARAMS in /etc/sysconfig/console if your system clock is set to UTC.
Please REOPEN this bug. Sorry, it isn't quite fixed, even in Raw Hide's apmd-3.0beta9-4, and there are numerous documentation issues that have contributed to the pain of solving this problem. I'm on a Toshiba Tecra 8000 in EST (UTC-5:00). I set the UTC variable in /etc/sysconfig/clock to true, false, yes, and no, and either did or didn't include a -u in the ADDPARAMS variable of /etc/sysconfig/apmd. I tested all 8 permutations. After saving the files each time, I did: /etc/rc.d/init.d/apmd restart ; rdate -s ntp1 ; setclock ; date Then I suspended and restarted twice, repeating the "date" command many times in succession during the restarts and watching the syslog messages. In each case, the time came back set to an initial value and was then advanced 5 hours. Sometimes this was done incorrectly, and frequently it was done against the instructions of the files. Here's the truth table. /etc/sysconfig clock apmd initial final yes -u -5 hr correct true -u correct +5 hr no -u -5 hr correct false -u -5 hr correct yes -5 hr correct true correct +5 hr no -5 hr correct false -5 hr correct BUG 1: If the UTC variable in /etc/sysconfig/clock is set to true, the behavior is incorrect. Unfortunately, this is the value that timeconfig sets it to, rather than yes. FIX 1: timeconfig should set it to yes, not true, and everyone reading the file should understand both true and yes. Document the favored value to use in the timeconfig and sysconfig man pages. Document the format of the /etc/sysconfig/clock file either on its own page or in timeconfig or sysconfig's pages. Currently its format is undocumented in the reference pages. BUG 2: The -u command line option to apmd, documented under comments of the ADDPARAMS variable of /etc/sysconfig/apmd, is completely ignored. FIX 2: The man page says the option is ignored. However, it also says the hardware clock is in UTC, which may be incorrect. The man page should be updated. The /etc/sysconfig/apmd file should have reference to -u removed. The lines in /etc/rc.d/init.d/apmd that ensure the -u option is set if UTC is set in /etc/sysconfig/clock, are not effective as they set a variable that is never referred to. The man pages for timeconfig, settime, and apmd refer to a program clock(8), which doesn't exist and neither does its man page. The correct reference and program are "hwclock". The man page for hwclock says it is the man page for clock(8). The man page for apmd doesn't give a section number after referring to hwclock. The man page for setclock doesn't name a program for reading the hardware clock, but should name hwclock and state its function. After all of this, there is still another problem. If I suspend with apm -s or by holding the power button in for 1 second (configured in the BIOS to suspend), things work fine if I'm configured with one of the methods that work above. However, this laptop has an emergency suspend when the battery runs out. When there is no power in the main batteries, it suspends and switches to a backup battery that keeps the system alive for 8 hours in suspend mode only. Resuming from one of these suspends causes the clock to lose 5 hours and not get it back. --jh--