Red Hat Bugzilla – Bug 249857
kernel update 126.96.36.199-33.fc7 can't tell the time
Last modified: 2007-11-30 17:12:11 EST
Description of problem:
Clock time does not change. Log out therefore fires an error assuming I was
logged in for less than 10 secs. System time is OK but fedora does not note
passage of true time. time adjust panel is faint and will not adjust, although
it does know true time. Log out goes to text mode only (ie no longer in X)
Version-Release number of selected component (if applicable):
Most recent kernal update
Steps to Reproduce:
1. just log in
System is totally unusable like this and I am now only using previous kernal
I expect it to be able to tell the time - after all the average 4 yr old can
It appears that the bug reporting system has allocated a low priority to this.
Given that the system is totally useless as is and therefore cannot be used, I
would say the priority is maximum. Peter
I've been seeing the same issue on my machine, along with several other errors.
The weird thing is that when I opened a shell and typed "date" it gave me the
correct date, but in the GNOME clock and gaim, etc. it was completely frozen.
When I reboot to the old kernel I don't see a problem.
Same problem here. Even the following simple program shows the problem:
int main (int argc, char *argv)
time_t now = time(NULL);
Output is always:
Sat Jul 28 00:44:40 2007
Fri Jul 27 23:29:39 CEST 2007
The test program always displays the same time. I'll let you know what happens
when the real time reaches the wrong time in 1h15 minutes. :-)
Same here, neither gdm nor xfce panel are able to show the correct time. Trying
to adjust xfce's date/time panel leads to complete lockup. Also logout from
desktop session results in text mode sinc X doesn't restart. Affected kernel is
188.8.131.52-33, while 184.108.40.206-27 just works fine.
Well, now that 'real time' has caught up with the 'fake time', the problem has
$ ./ctime && date
Sat Jul 28 00:48:59 2007
Sat Jul 28 00:48:59 CEST 2007
I also had the X restart problem, which has now also gone away.
Ah, now I see some logic. Looks like the system is adding the difference
between Greenwich mean time and my location time (Perth in Australia)twice,
rather than once.
My stopped clock is plus 16h exactly on GMT and should only be plus 8h.
After that trying to log out simply fires confusion as system cannot cope
adequately with a time in the future: indeed error message says "that should not
Same problem here ...
I wrote a little C-programm. The functions ctime, time and localtime do not work
ctime and time always give back the time when the kernel was started and
localtime always gives back UTC-time (does not resprct the time zone).
This kernel (220.127.116.11-33.fc7) is not usable at all with this bug.
Back to 2.6.21-1.3228.fc7 (the last usable kernel for me).
I was also knocked by the same issue.
According to my research, with "18.104.22.168-33", a clock of GNOME Desktop displays
wrong time, but NTP works well and returns me correct time(example,
"system-config-date" shows me correct time).
So, I am useing 22.214.171.124-3228; the kernel that don't switch off ATA-HDD before
shutdown on my environment...
I have the same Problem.
date shows the right time, the gnome clock stays at the same time, even the
timestamps in syslog don't proceed. They show the time I turned on the computer
+2h (my timezone is utc+1+daylight savings). my hw clock is set to my localtime,
not to utc
It seems that KDE doesn't suffer of the bug...
The only workaround for now is to use kernel-126.96.36.199-27.fc7
Tools like "make" complain heavily (as they depend on the correct
time and date), and gkrellm's time display is also confused.
After boot, the time is wrong for the current GMT offset
(my computer runs at GMT +0200, and the new kernel adds
additional two hours). The time seems to go better if I
wait that amount of time (two hours).
The new kernel is unusable. On the other hand, I'm pretty sure
that some people may not notice the problm at all if they don't
do anything that depends on correct time and date.
I'm wondering that the "Priority" field of this bug is set to "low".
Nowadays, wrong time and date can result in very nasty things.
kernel 188.8.131.52-41.fc7 from here
http://koji.fedoraproject.org/koji/buildinfo?buildID=12174 resolved this bug
*** Bug 249942 has been marked as a duplicate of this bug. ***
When would this kernel be pushed to update repository?
*** Bug 250049 has been marked as a duplicate of this bug. ***
*** Bug 249981 has been marked as a duplicate of this bug. ***
I guess this kernel had default priority, changing to "urgent". I agree
184.108.40.206-33.fc7 is not usable.
My symptom was a broken xchat, so it was difficult to ask for help.It took me 2
hours experimenting with all kinds of things before I suspected the kernel.
Both kernel -27.fc7 and the kernel from comment 13 work for me.
(In reply to comment #19)
> I guess this kernel
... bug, not kernel
FYI, my XFCE showed a broken time, too, but this was the first time I tried
xfce, so I suspected a bug in xfce rather than the kernel
Same problem too.
The best workaround is to remove kernel 1-33. Temporary workaround could be to
"legalize" this time difference by changing localtime to UTC (/etc/sysconfig/clock)
Another problem with time:
[user@compy]# dmesg | grep Date
Time: 18:50:47 Date: 06/30/107
(it's current time and day)
What this Date mean?
*** Bug 249878 has been marked as a duplicate of this bug. ***
*** Bug 250066 has been marked as a duplicate of this bug. ***
Kernel from comment 13 works and also fixes bug #249950 for me.
Related to https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249857#c16 and
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=250003 (also a major issue)
perhaps as an intermediate solution, imho a kernel rollback should be made
(using EPOCH), if pushing a fixed kernel from testing to update needs some more
*** Bug 250373 has been marked as a duplicate of this bug. ***
I guess this bug can be marked resolved currentrelease, because I can see the
updated kernel package in the f-7 updates download area, and it fixes the bug
Please comment or reopen the bug if you still have the problem.
*** Bug 249918 has been marked as a duplicate of this bug. ***