Hide Forgot
My hardware clock keeps the time in "localtime" as opposed to "utc". The time is set correctly by rc.sysinit at boot time but after about 15 min it will jump by 1h (which is just the time offset for me). If I reset the time to the correct value it will be changed to the wrong value after about 15min. Problem was not present in beta1 and beta2.
This defect is considered MUST-FIX for Florence Gold release
Are you running ntpd?
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@redhat.com>...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.