Bug 26722

This defect is considered MUST-FIX for Florence Gold release

Are you running ntpd?

This defect is considered MUST-FIX for Florence Gold release

No I am not running ntpd (or anything similar).

I haven't heard this from other people, so it must be hardware-specific.
Could you please list your hardware?

This is an ASUS L7400 laptop. It is in the beta hw database #12.

Are you using framebuffer?

Oh, and are you suspending and resuming?

What happens if you stop apmd -- does this quit happening?

No. I use the XF86_SVGA server.

Turning off apmd makes no difference.

Are you suspending and resuming?

Yes. But it makes no difference wether I do a suspend/resume or a full reboot.

This sounds like an apm event setting your machine to GMT -- whether
system time is GMT or localtime is a compile-time setting for APM and
we set it to GMT.  But I assume that you are not intentionally causing
an apm event when the time jumps, is that correct?

No I am not intentionally causing an apm event.

Still broken in qa0322

The same issue is showing up on my laptop (DELL Latitude CPxJ PIII 650 with 256
Mb RAM) only with 5 hours (18000 seconds) instead of 1 hour.  The clock is set
back 5 hours anytime I logon.  If I reset the system time, the next time I login
to GNOME, the time jumps back by 5 hours.  This is recreatable.  Before are
entries from my boot log.  The time is correct when I boot the system.  I don't
think this is a hardware issue.  Up until three days ago I was running 7.0 and
things were fine.

  May 10 07:29:18 cmilfo date: Thu May 10 07:29:12 CDT 2001 
  May 10 07:29:18 cmilfo rc.sysinit: Setting clock  (localtime): Thu May 10
07:29:12 CDT 2001 succeeded 

I have another machine (not a laptop) running 7.1, also.  I have not been able
to recreate the problem on it.

Are you running apmd ?
Can you use the rdate or ntpdate program to sync your SYSTEM clock
to a correct time ?

Yes, I am running apmd.  And yes, I have been using rdate to set my SYSTEM
clock.  I tried syncing to more than one site to make sure that one wasn't
corrupt.

I am seeing the same symptoms on a Dell Latitude C600 laptop.  However, on my system I see no signs that it is related to APM.  Believe it or not, it 
seems to be caused by the X server....

After booting into single-user mode, both the hardware and system clocks show correct local time.  Switching to multi-user mode does not change this.  
However, once the X server is started (without starting an X shell, using the "X" command), the system time has now been set back by the number of 
hours my local timezone differs from UTC.  If the system is then shut down, this incorrect system time gets copied to the hardware clock by the init script.

Before determining this, I investigated APM, and found that 1) no APM events were being generated during a normal boot, and 2) the apmscript is 
correctly determining the clock mode from /etc/sysconfig/clock.  In fact, doing an APM suspend and then resume corrected the system clock on my 
machine, because the script does a "hwclock --hctosys".

My apologies to <johnsonm>...this is indeed APM-related, as he indicated previously.

APM is invoked by (at least some) X servers when they start up.  APM behavior is controlled, in part, by the CONFIG_APM_RTC_IS_GMT kernel build 
option, which is set to y in Red Hat builds.

Rebuilding the kernel with this option commented out fixed the problem on my system.

This just happened to me out of the blue.  (Also Latitude CPx-J.)

I was doing nothing with the machine, logged in and running X.  Sometime around
19:40 local time, the system clock jumped back to 15:40.  My XFree86.0.log
contains a number of lines like:

(II) PM Event received: Power Status Change
(II) PM Event received: Power Status Change
(II) PM Event received: Power Status Change

I have a flexlm license manager that noticed the problem, but no other
indications in the logs of any unusual events.

There have been a couple of these since I reset the clock and they have not
caused the clock to change again.  They seem to be occuring every couple of minutes.

The hardware clock remains correct when this happens until shutdown, at which
point the incorrect time is saved to the hardware clock.

Regarding the CONFIG_APM_RTC_IS_GMT issue, it certainly seems like a serious
problem if I need to *recompile my kernel* just to deal with my hardware clock
running in local time vs. UTC.  This says that either every customer that
dual-boots windows or every customer that doesn't will need to recompile a
kernel to have a functional system....

I do no longer see this problem.