This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 4777 - resumes don't account for UTC with APM compiled into kernel
resumes don't account for UTC with APM compiled into kernel
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
6.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ben LaHaise
:
: 7712 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-08-30 03:14 EDT by Graham Mainwaring
Modified: 2007-04-18 12:23 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-14 13:47:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Graham Mainwaring 1999-08-30 03:14:03 EDT
My system time unpredictably jumps back to 4 hours in the
past. This happens a couple times a week, but I can't pin
down any correspondences; it just seems to happen on random
occasions. The following syslog extract shows an example:

Aug 29 16:22:11 porter dhcpd: DHCPREQUEST for 10.1.1.77 from
00:00:f8:07:60:17 via eth0
Aug 29 16:22:11 porter dhcpd: DHCPACK on 10.1.1.77 to
00:00:f8:07:60:17 via eth0
Aug 29 12:27:30 porter dhcpd: DHCPINFORM from 10.1.1.35
Aug 29 12:36:28 porter dhcpd: DHCPREQUEST for 10.1.1.76 from
00:40:33:51:4d:90 via eth0
Aug 29 12:36:28 porter dhcpd: DHCPACK on 10.1.1.76 to
00:40:33:51:4d:90 via eth0

From this point forward, the time was exactly 4 hours slow.
I typically correct the problem by running ntpdate, which
always reports an offset of very close to 3600, although it
is sometimes a few seconds off. Probably not coincidentally,
I am in the EDT timezone, which happens to be 4 hours behind
GMT.

I am not running xntpd or anything similar; nothing called
from cron tries to set the time; and I can't see how any of
the daemons I'm running would be interested in changing the
time. I was running oclock in my gdm login screen at the
time I first observed this problem, but I took it out and
the problem persists.

On one occasion, the time warp happened during a boot:

Aug 29 04:37:14 porter kernel: Trying to unmount old root...
okay
Aug 29 04:37:14 porter kernel: Freeing unused kernel memory:
60k freed
Aug 29 00:36:50 porter rc.sysinit: Loading default keymap
succeeded
Aug 29 00:36:50 porter rc.sysinit: Setting default font
succeeded

Again, I cannot locate anything that occurs between the end
of kernel initialization and the point in rc.sysinit where
the "Loading default keymap" message was printed that could
possibly affect the time. The actual wall clock time when
this particular example occurred was ~4:30AM and I had just
checked the BIOS time and found it to be correct. In fact,
on the several occasions when I've checked the BIOS time, it
has always matched the wall clock, even when Linux has been
reporting the wrong time. The time is always correct on
boot, and seems to remain 4 hours off indefinitely, until
you reset it. Once you've reset it, it will go wrong again
during the same session; in other words, you can have the
time warp occur more than once per boot.

This is a Linux-only system, so I can't try running Windows
or whatever to see if the problem persists across OSs. For
the record, the machine is a Tyan Tsunami motherboard, Intel
440BX chipset, with a single PII-400; it has a Buslogic SCSI
controller with a 4Mb Seagate Cheetah and a WangDAT tape
drive attached to the wide and narrow channels respectively;
there is also a large IDE hard drive, ATAPI CD-ROM, and I
have recently installed an ATAPI CD-R/CD-RW burner using the
ide-scsi driver. The time warp was occurring before I
installed the burner and the addition of the burner does not
seem to have affected thefrequency of occurrences. All
hardware is recent, was purchased through reputable
distributors, and has always been run on a line conditioning
UPS. That having been said, I have no way of guaranteeing
this is not some kind of hardware failure. I have not seen
this problem on any other machine. Also, the system is
straight RH6, as originally delivered; nothing from
updates.redhat.com has yet been applied. The same system
previously ran RH5.2 and this problem did not occur. As
close as I can figure it, the problem began at the time I
upgraded to RH6 several weeks ago. I did not use the
"upgrade" feature of the installer, I reformatted and
installed from scratch.

The behavior I'm reporting here is similar to what was
reported in an earlier bug with apmd. However, this is not
(at least overtly) the same bug, as it is not associated
with suspend/restore. My system is a desktop, all power
saving features in the BIOS are turned off, and it is not
running apmd. Also, logs showing this problem frequently
occur with other activity just a minute or two on either
side; these occurrences do not seem to correspond with
system inactivity, although I can't say I've ever witnessed
it happening while I was actually logged in to the machine.

I have reported this problem as associated with the
component "time" -- which is clearly wrong, but since I
don't know what's causing it, I can't pick anything better.

-Graham
Comment 1 Preston Brown 1999-08-30 16:38:59 EDT
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.
Comment 2 Graham Mainwaring 1999-08-31 00:19:59 EDT
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.
Comment 3 Graham Mainwaring 1999-09-08 01:26:59 EDT
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.
Comment 4 Duane Voth 1999-09-09 00:29:59 EDT
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
Comment 5 Graham Mainwaring 1999-09-17 02:46:59 EDT
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
Comment 6 tchrist 2000-01-29 12:21:59 EST
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.
Comment 7 Graham Mainwaring 2000-01-29 15:53:59 EST
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
Comment 8 Graham Mainwaring 2000-02-02 08:01:59 EST
I have upgraded to Red Hat Linux 6.1 and all the latest updates from
priority.redhat.com, and the problem persists.
Comment 9 Bill Nottingham 2000-02-05 15:44:59 EST
*** Bug 7712 has been marked as a duplicate of this bug. ***
Comment 10 Bernhard Rosenkraenzer 2000-02-16 07:58:59 EST
Try updating to the Raw Hide apmd.
Comment 11 Graham Mainwaring 2000-02-16 14:34:59 EST
Can you explain this a little? Does it still make sense if the machine having
the problem is not currently running apmd?

-Graham
Comment 12 Thomas D. Shepard 2000-03-21 22:39:59 EST
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.
Comment 13 Graham Mainwaring 2000-04-17 18:08:59 EDT
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
Comment 14 Thomas D. Shepard 2000-04-18 01:11:59 EDT
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.
Comment 15 Willem Jan Palenstijn 2000-05-26 13:47:59 EDT
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
Comment 16 Willem Jan Palenstijn 2000-07-30 16:38:20 EDT
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
Comment 17 Luca Bonomi 2000-10-30 09:39:29 EST
well, this time warp problem still persist on redhat 7.0!
Comment 18 Preston Brown 2001-02-05 15:33:02 EST
we are investigating this again for our next release.
Comment 19 Harald Hoyer 2001-02-05 16:27:36 EST
[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.
Comment 20 Preston Brown 2001-02-14 20:32:58 EST
can we see your /etc/adjtime contents if you are having problems?
Comment 21 Preston Brown 2001-03-05 12:53:49 EST
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.
Comment 22 Graham Mainwaring 2001-10-10 13:31:59 EDT
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.
Comment 23 Ben LaHaise 2002-06-03 17:41:17 EDT
This should be made a sysctl, if not already in 2.4.
Comment 24 Stephen John Smoogen 2003-01-24 13:20:09 EST
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.
Comment 25 Jay Turner 2003-04-14 13:47:55 EDT
Killing this bug off as we're no longer seeing it.
Comment 26 Cedric Dufour 2003-08-08 09:14:57 EDT
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...

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