From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
Running RH9 on a Winbook XLi laptop. Shortly after loading battstat on the menu
bar, the system time falls behind by exactly 4 hours (to the second). The change
to the system time was verified with both the clock applet and via the "date"
command on the command line.
Even if I correct it by setting the clock back to the correct time, it will
again lose 4 hours within a few minutes. It doesn't drift, it happens instantly,
as if the clock was manually adjusted. The system does not use NTP or any other
time manipulation utility.
Once the clock has lost the 4 hours, and I exit X, the system will lose another
4 hours once I go back into X resulting in a loss of 8 hours (to the second).
Unloading and reloading the applet alone didn't seem to have the same effect. I
had to exit and restart X.
Note that if I load the applet shortly after midnight, the clock adjusts the
time back by 4 hours and the date back by one day. For example, if the applet
exhibits this bug at 0:15:01 on October 3, the clock will change to 20:15:02
October 2. This may or may not point to an issue with timezone libraries...
although why would a battery monitor that doesn't predict runtime in minutes
care what time it is? Curious.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add battstat monitor to menu bar
2. Wait a few minutes
Actual Results: System lost time (4 hours) every time the battstat applet was
added to the menu bar.
Expected Results: Certainly the clock shouldn't change. I'm not getting
younger, after all. ;)
It's interesting to note that this behavior occured when I was logged into the
computer under a normal user account (not root). Only root should be able to
modify the system time.
Has to be a hardware/bios/kernel issue, I would think.
I would tend to agree. Upon further investigation, the bug exhibits itself when
I activate the battery monitor in GKrellM (www.gkrellm.net) and even by simply
using the command line tool "apm".
Possibly an APM BIOS issue. Any update available ?
Another interesting experiment might be rebuilding a kernel with
CONFIG_APM_ALLOW_INTS=y and seeing if that makes a difference.
I can try a new kernel with CONFIG_APM_ALLOW_INTS=y. Can you supply me with a
.config file for a stock RH kernel?
Linux nomad 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386 GNU/Linux
You can find them in the kernel SRPM.
Just pick the one relevant to your system.
I used the configs/kernel-2.4.20-i686.config and set CONFIG_APM_ALLOW_INTS=y and
then made a bzdisk. When I booted off the floppy, it halted as soon as it tried
to uncompress the kernel with the error "invalid compression format (err=2)",
which is a new one to me.
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases,
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/