Bug 4777
| Summary: | resumes don't account for UTC with APM compiled into kernel | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Graham Mainwaring <graham> |
| Component: | kernel | Assignee: | Ben LaHaise <bcrl> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.1 | CC: | bero, cdufour-keyword-redhat.b506d8, duanev, graham, gwortel, palenstijn, pbrown, tchrist, tdshepard |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-04-14 17:47:55 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Graham Mainwaring
1999-08-30 07:14:03 UTC
you probably have your computer up to boot with the assumption that the bios holds UTC instead of EST. if /etc/sysconfig/clock doesn't contain the line: UTC=true then please re-open this bug. Otherwise, change that to say: UTC=false and your problem will disappear. Naturally, that was one of the first things I checked. /etc/sysconfig/clock contains UTC=false and ARC=false, and /etc/localtime is symlinked to /usr/share/zoneinfo/US/Eastern. I have also done an rpm --verify against glibc-2.1.1-6.i386.rpm to make sure that the zone files themselves are not somehow corrupted. Also, of course, if UTC=true were set, the system would boot up and set the time as if the BIOS clock were UTC, and then keep "correct" time from then on. That is not what is happening here. At unpredictable intervals, a couple times a week, the time drops back four hours, not related to any reboot, suspend/restore, or any other such thing. I have done some additional testing to see if this could be some kind of hardware problem. I have added another hard drive and installed Windows 95 on it. The system ran for a little over 24 hours without a time warp (or a crash - hey, not bad for Windows). I have also noticed that during one of these time warps, "hwclock" reports the correct time, so I can fix it by doing "hwclock -hctosys" instead of using ntpdate. Based on these two observations, I think the chances of it being hardware related are vanishingly small. However, of the dozen or so RH6 machines under my purview, the problem still only occurs on this one. I have yet to determine what is unique about this installation. Add me to the fray on this one, my machine also jumps back by the amount of my local time offset (5 hours for me - CDT). Note that the time jumps *back* to some timezone "in the pacific ocean" (or California for you graham) and not forward to match GMT. It is like the local time offset is being applied twice. I've tried both UTC=false and UTC=true with the same results! One test I ran was to place ntpdate in a 1 minute loop: (edited for readability) 8 Sep 20:45:03 ntpdate[11793]: adjust 0.004865 sec 8 Sep 20:46:03 ntpdate[12117]: adjust -0.006261 sec 8 Sep 20:47:12 ntpdate[12454]: step 18022.993655 sec 8 Sep 20:48:12 ntpdate[12788]: adjust -0.000228 sec 8 Sep 20:49:12 ntpdate[13119]: adjust 0.003379 sec 8 Sep 20:50:12 ntpdate[13455]: adjust -0.002956 sec 8 Sep 20:51:12 ntpdate[13788]: adjust 0.003558 sec 8 Sep 20:52:13 ntpdate[14119]: adjust 0.002874 sec 8 Sep 20:53:13 ntpdate[14450]: adjust -0.000216 sec 8 Sep 20:54:18 ntpdate[14791]: step 18022.979984 sec 8 Sep 20:55:18 ntpdate[15122]: adjust 0.000473 sec 8 Sep 20:56:19 ntpdate[15453]: adjust 0.004785 sec 8 Sep 20:57:19 ntpdate[15784]: adjust -0.002653 sec 8 Sep 20:58:19 ntpdate[16108]: adjust 0.009691 sec 8 Sep 20:59:19 ntpdate[16447]: adjust -0.008540 sec 8 Sep 21:00:20 ntpdate[16764]: adjust 0.004738 sec 8 Sep 21:01:20 ntpdate[17093]: adjust -0.002813 sec 8 Sep 21:02:20 ntpdate[17419]: adjust 0.008220 sec 8 Sep 21:03:20 ntpdate[17743]: adjust -0.006958 sec 8 Sep 21:04:21 ntpdate[18060]: adjust 0.005848 sec 8 Sep 21:05:21 ntpdate[18391]: adjust -0.002714 sec 8 Sep 21:06:21 ntpdate[18722]: adjust 0.012182 sec 8 Sep 21:07:23 ntpdate[19060]: step 18022.962198 sec 8 Sep 21:08:24 ntpdate[19397]: adjust 0.001568 sec 8 Sep 21:09:24 ntpdate[19723]: adjust 0.004171 sec 8 Sep 21:10:25 ntpdate[20054]: adjust -0.005165 sec 8 Sep 21:11:25 ntpdate[20371]: adjust 0.004265 sec 8 Sep 21:12:25 ntpdate[20681]: adjust 0.003980 sec 8 Sep 21:13:26 ntpdate[21010]: adjust -0.006889 sec 8 Sep 21:14:45 ntpdate[21210]: step 18023.010783 sec 8 Sep 21:15:45 ntpdate[21213]: adjust -0.009385 sec There doesn't seem to be much rhyme nor reason to when the jump occurs. I thought it might be a cron/anacron thing but they don't seems to be involved at this frequency. Also I've seen the system keep the correct date for hours at a time instead of only minutes, but don't know what changed to make it now a more frequent problem. One question I have is why isn't the TZ variable set in the /etc/bashrc or wherever it is supposed to get set? Mine is blank. /etc/localtime however is fine. What is the standard API for localtime these days?? /etc/localtime -> ../usr/share/zoneinfo/US/Central Duane, can you confirm that your hardware clock is correct when this
problem occurs; i.e. that it's a problem in Linux itself, rather than
your hardware? I have just started running the following script once
per minute from crontab, and will post results in a couple days:
#!/bin/sh
hwclk=`/sbin/hwclock`
sysclk=`/bin/date`
hwhm=`echo $hwclk | awk '{print $4}' | awk --field-separator ':'
'{print $1 ":" $2}'`;
syshm=`echo $sysclk | awk '{print $4}' | awk --field-separator ':'
'{print $1 ":" $2}'`;
if test ! "$hwhm" = "$syshm"; then
echo Sys: $sysclk Hw: $hwclk >> /var/log/timeerr
/sbin/hwclock --hctosys
fi
I have reasonably conclusive evidence that the timewarp (which is equal to your system's offset from GMT, but sets it back, not forward) occurs whenever your console monitor has gone idle and you hit a key or the mouse, waking it up. That's when the time jump strikes. It's so annoying that I have little cronjobs launching minutely to fix it. But that doesn't work, because the temporal fugue freaks out cron, too. So I end up having to have cron running on a completely different machine (not afflicted with this problem; different O/S) do the fix. The most common time I notice the time warp is when I first walk up to the machine and log in, which of course causes the screen to un-blank. However, there have been times when I've come out of screen saver mode but no time warp has occurred, and I'm pretty sure there are also times when the time warp occurs while the screen is blanked and stays that way. Also, there appear to be times when it only "warps" one hour instead of four. Last but not least, during this time I've upgraded from kernel-2.2.5-15 to kernel-2.2.5-22 and have applied all currently available updates to Rh6.0. I'm going to upgrade to Rh6.1 at some point and will report whether the problem persists. It would be nice to know that somebody at Red Hat is aware of this. No response for months is getting a bit frustrating. The following is my log of when this has happened. The reason there are no entries for the first half of December is that I was on vacation and the machine was powered off. However, I have no explanation why the problem apparently went into remission for the first two weeks of November. -------------------- Sys: Fri Sep 17 07:50:04 EDT 1999 Hw: Fri Sep 17 11:50:04 1999 -0.635981 seconds Sys: Fri Sep 17 15:50:59 EDT 1999 Hw: Fri Sep 17 15:51:01 1999 -0.693337 seconds Sys: Fri Sep 17 16:51:03 EDT 1999 Hw: Fri Sep 17 20:51:03 1999 -0.653828 seconds Sys: Sat Sep 18 19:27:09 EDT 1999 Hw: Sat Sep 18 23:27:09 1999 -0.859303 seconds Sys: Mon Sep 20 17:34:11 EDT 1999 Hw: Mon Sep 20 21:34:11 1999 -0.340705 seconds Sys: Wed Sep 22 03:25:12 EDT 1999 Hw: Wed Sep 22 07:25:12 1999 -0.534250 seconds Sys: Mon Sep 27 04:19:38 EDT 1999 Hw: Mon Sep 27 08:19:38 1999 -0.092578 seconds Sys: Mon Sep 27 22:18:07 EDT 1999 Hw: Tue Sep 28 02:18:07 1999 -0.311133 seconds Sys: Thu Sep 30 03:25:10 EDT 1999 Hw: Thu Sep 30 07:25:09 1999 -0.522284 seconds Sys: Thu Oct 7 18:18:36 EDT 1999 Hw: Thu Oct 7 22:18:36 1999 -0.999960 seconds Sys: Sun Oct 10 14:24:22 EDT 1999 Hw: Sun Oct 10 18:24:22 1999 -0.474225 seconds Sys: Mon Oct 11 16:16:10 EDT 1999 Hw: Mon Oct 11 20:16:10 1999 -0.949836 seconds Sys: Wed Oct 13 18:32:17 EDT 1999 Hw: Wed Oct 13 22:32:17 1999 -0.537312 seconds Sys: Fri Oct 15 04:54:12 EDT 1999 Hw: Fri Oct 15 08:54:12 1999 -0.824893 seconds Sys: Sun Oct 17 22:13:21 EDT 1999 Hw: Mon Oct 18 02:13:21 1999 -0.667137 seconds Sys: Sun Oct 24 10:00:49 EDT 1999 Hw: Sun Oct 24 14:00:49 1999 -0.711009 seconds Sys: Sun Oct 31 01:00:01 EST 1999 Hw: Sun Oct 31 02:00:15 1999 -0.900548 seconds Sys: Thu Nov 18 03:58:20 EST 1999 Hw: Thu Nov 18 08:58:20 1999 -0.926350 seconds Sys: Thu Nov 18 16:58:05 EST 1999 Hw: Thu Nov 18 21:58:05 1999 -0.743488 seconds Sys: Sun Nov 21 11:28:05 EST 1999 Hw: Sun Nov 21 16:28:05 1999 -0.287007 seconds Sys: Mon Nov 22 18:12:07 EST 1999 Hw: Mon Nov 22 23:12:07 1999 -0.526489 seconds Sys: Fri Nov 26 17:26:30 EST 1999 Hw: Fri Nov 26 22:26:30 1999 -0.881392 seconds Sys: Thu Dec 2 17:10:23 EST 1999 Hw: Thu Dec 2 22:10:23 1999 -0.040937 seconds Sys: Sun Dec 12 12:29:12 EST 1999 Hw: Sun Dec 12 17:29:12 1999 -0.301895 seconds Sys: Tue Dec 14 16:22:17 EST 1999 Hw: Tue Dec 14 21:22:17 1999 -0.021612 seconds Sys: Mon Jan 3 15:52:28 EST 2000 Hw: Mon Jan 3 20:52:28 2000 -0.867855 seconds Sys: Fri Jan 7 12:17:30 EST 2000 Hw: Fri Jan 7 17:17:30 2000 -0.991353 seconds Sys: Fri Jan 7 21:17:01 EST 2000 Hw: Fri Jan 7 22:17:01 2000 -0.402428 seconds Sys: Sat Jan 8 23:52:02 EST 2000 Hw: Sun Jan 9 04:52:02 2000 -0.366242 seconds Sys: Sun Jan 9 04:13:58 EST 2000 Hw: Sun Jan 9 05:14:01 2000 -0.434723 seconds Sys: Sun Jan 9 11:09:01 EST 2000 Hw: Sun Jan 9 16:09:01 2000 -0.218701 seconds Sys: Sun Jan 9 15:19:58 EST 2000 Hw: Sun Jan 9 16:20:01 2000 -0.340905 seconds Sys: Sun Jan 9 18:24:01 EST 2000 Hw: Sun Jan 9 23:24:01 2000 -0.399753 seconds Sys: Mon Jan 10 16:54:02 EST 2000 Hw: Mon Jan 10 21:54:02 2000 -0.024398 seconds Sys: Mon Jan 10 22:55:58 EST 2000 Hw: Mon Jan 10 23:56:01 2000 -0.381175 seconds Sys: Tue Jan 11 19:58:02 EST 2000 Hw: Wed Jan 12 00:58:02 2000 -0.872243 seconds Sys: Sun Jan 16 06:16:59 EST 2000 Hw: Sun Jan 16 06:17:01 2000 -0.270632 seconds Sys: Mon Jan 17 18:51:02 EST 2000 Hw: Mon Jan 17 23:51:02 2000 -0.328290 seconds Sys: Mon Jan 17 23:52:54 EST 2000 Hw: Tue Jan 18 00:53:01 2000 -0.937009 seconds Sys: Tue Jan 18 00:56:55 EST 2000 Hw: Tue Jan 18 01:57:02 2000 -0.940967 seconds Sys: Tue Jan 18 01:23:55 EST 2000 Hw: Tue Jan 18 02:24:02 2000 -0.902083 seconds Sys: Tue Jan 18 07:48:01 EST 2000 Hw: Tue Jan 18 12:48:01 2000 -0.426541 seconds Sys: Tue Jan 18 15:01:02 EST 2000 Hw: Tue Jan 18 20:01:02 2000 -0.161875 seconds Sys: Thu Jan 20 04:57:01 EST 2000 Hw: Thu Jan 20 09:57:01 2000 -0.210363 seconds Sys: Thu Jan 20 15:05:01 EST 2000 Hw: Thu Jan 20 20:05:01 2000 -0.033177 seconds Sys: Sat Jan 22 16:54:01 EST 2000 Hw: Sat Jan 22 21:54:01 2000 -0.237491 seconds Sys: Mon Jan 24 15:51:01 EST 2000 Hw: Mon Jan 24 20:51:01 2000 -0.414178 seconds Sys: Tue Jan 25 11:33:01 EST 2000 Hw: Tue Jan 25 16:33:01 2000 -0.108983 seconds Sys: Wed Jan 26 10:04:02 EST 2000 Hw: Wed Jan 26 15:04:02 2000 -0.980385 seconds Sys: Wed Jan 26 17:59:01 EST 2000 Hw: Wed Jan 26 22:59:01 2000 -0.346197 seconds Sys: Thu Jan 27 07:47:01 EST 2000 Hw: Thu Jan 27 12:47:01 2000 -0.171958 seconds Sys: Thu Jan 27 13:56:01 EST 2000 Hw: Thu Jan 27 18:56:01 2000 -0.836212 seconds Sys: Thu Jan 27 19:06:01 EST 2000 Hw: Fri Jan 28 00:06:01 2000 -0.755468 seconds Sys: Fri Jan 28 12:16:01 EST 2000 Hw: Fri Jan 28 17:16:01 2000 -0.551576 seconds Sys: Fri Jan 28 20:27:01 EST 2000 Hw: Sat Jan 29 01:27:01 2000 -0.420916 seconds Sys: Sat Jan 29 10:44:01 EST 2000 Hw: Sat Jan 29 15:44:01 2000 -0.776355 seconds I have upgraded to Red Hat Linux 6.1 and all the latest updates from priority.redhat.com, and the problem persists. *** Bug 7712 has been marked as a duplicate of this bug. *** Try updating to the Raw Hide apmd. Can you explain this a little? Does it still make sense if the machine having the problem is not currently running apmd? -Graham I have been watching this bug for a while because I am having the same problem. My time warps 8 hours in the past, which is exactly PST-UTC where PST is my current local time. Graham, are you sure you are not running apmd? My machine is not a laptop, so at first thought I might think I am not running it, but I am. apmd handles starting back up from standby mode, which I can put my machine in by invoking apm (as root) or by punching the power button without holding it in. So I tried an experiment. If the system time (reported by date) is not correct, I first reboot, which seems to always fix the time. Then I type thomas[1] date Tue Mar 21 19:16:35 PST 2000 which reveals the correct local time. Then I put the computer to sleep and move the mouse or push the power button to wake it back up. Then I get thomas[2] date Tue Mar 21 11:16:59 PST 2000 which is the incorrect warped time. This seems to happen every time. I suppose I could disable apmd and repeat the experiment. I am running apmd version 3.0beta9. Isn't this the latest version? The "beta" in the version number doesn't give me a very warm feeling. I am definitely not running apmd and I have definitely seen the bug at times that are unrelated to suspend/restore. It seems to happen most frequently when gnome starts up immediately after logging in via gdm. It does happen more often when the system's been sitting for a while, but the BIOS in this particular system has no power management or anything else, and apmd is not even installed. Although the same problem happened back when apmd was installed. -Graham I have determined that in my case the problem definitely IS caused by apm. I can reproduce the behavior any time I want just by going into power-save mode and coming back out. I have disabled apm and have had no further problems. However, it is now a nuisance to have to stay logged in and run a screen saver as a poor-man's poor substitute for apm. When restarting from power-save mode, one of the steps taken by apmd is to reset the system clock, which it does incorrectly. The problem seems to be that the system for keeping track of time zones is a jumbled mess --- in short, a software engineers nightmare. What seems like a very simple software item is messed up because basic principles of software engineering were violated. If I understand this correctly, any app that attempts to set the clock can have this problem if the spaghetti logic is not correctly set up. Others have posted detailed descriptions of the problem. It seems like it should be easy to fix. I seem to be suffering from the same problem. My system is a P200 running RedHat 6.2. Every ten minutes (give or take a few seconds) my clock warps 2 hours forward. (I live in the Netherlands, GTM +2) On startup, the clock is ok, but a few minutes later it is warped. When I reset it, it is warped again ten minutes later. When it gets warped, the machine also freezes a few seconds, blocking all network traffic. (I'm usually logged in on this machine using ssh) When running top with a high refresh rate, it shows 'top' at the top, with 20% CPU, sshd popping up every now and then. When the warp occurs, top also freezes for a while, and as soon as it comes back up, 'init' is at the top of the list. (with the usual CPU usage, btw) Another thing that may be related: May 26 07:09:52 mara kernel: ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio May 26 07:09:37 mara rc.sysinit: Mounting proc filesystem succeeded (Notice the time warp of 15 secs) (When this happens during bootup, it says init is starting) I'm not running any time related services or apmd. Also, my HW clock is not set to GMT. (Disabling cron doesn't seem to help either) Hope this helps somehow. -Willem Jan I found a way to solve this problem for me. There is a kernel option APM_RTC_IS_GMT. I recompiled the kernel with this option turned off, and the time warps disappeared. -Willem Jan well, this time warp problem still persist on redhat 7.0! we are investigating this again for our next release. [harald@faro harald]$ cat /etc/adjtime -5.774782 981019816 0.000000 981019816 UTC In /etc/adjtime there may be a difference of 4 hours. Set the time and date. Remove /etc/adjtime. Put it in the BIOS with hwclock --systohc. Remove /etc/adjtime. can we see your /etc/adjtime contents if you are having problems? Michael: the option APM_RTC_IS_GMT needs to be accessible through /proc to fix this problem. I have the same issue on my laptop when coming back from a suspend. Just ran into this problem yet again. This time it's on a Dell 2450 running 7.1 with all current updates applied. And on this machine, it's not intermittent. If I set the time with ntpdate, it won't be a whole minute before it's four hours in the past again. However, if I set the hardware clock to UTC, it seems to be happy. Just wanted you to know (if you don't already) that this is not fixed in 7.1, and continues to appear on a diverse range of hardware. The workaround is, always set your system clock to UTC. This won't work for people who want to dual-boot to Windows, but it seems to work okay for Linux-only boxen. This should be made a sysctl, if not already in 2.4. Need to see if this problem is still occuring in 7.3/8.0 release. I have been unable to duplicate it on a 400 machine network of dual boot machines none of them set to UTC in system bios. Killing this bug off as we're no longer seeing it. Using RH 7.3 (kernel 2.4.20-19.7: CONFIG_APM_RTC_IS_GMT=y), TZ=Europe/Zurich, UTC=false, I experience the same problem (having the system clock suddenly jump 2 hours forward). So far, I have a cron job synching system clock to hardware clock every 5 minutes (and notifying me when offset is bigger than 5 seconds). I launched process accounting to find out if any command/process might me involved in it. To no avail. *** The one thing peculiar about my system is that I mentionned UTC hardware clock during RH initial installation and later switch back to hardware local time for convenience purposes (experiencing the problem since then). Maybe this is a clue... *** So it seems this bug is still to be looked for :-(, though it is bot clear whether it is APM related or not... |