This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 249857 - kernel update 2.6.22.1-33.fc7 can't tell the time
kernel update 2.6.22.1-33.fc7 can't tell the time
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
i686 Linux
urgent Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 249878 249918 249942 249981 250049 250066 250373 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-27 10:21 EDT by Peter Garcia-Webb
Modified: 2007-11-30 17:12 EST (History)
21 users (show)

See Also:
Fixed In Version: kernel-2.6.22.1-41.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-03 09:10:12 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 Peter Garcia-Webb 2007-07-27 10:21:11 EDT
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

How reproducible:
Very.

Steps to Reproduce:
1. just log in
2.
3.
  
Actual results:
System is totally unusable like this and I am now only using previous kernal

Expected results:
I expect it to be able to tell the time - after all the average 4 yr old can
Additional info:
Comment 1 Peter Garcia-Webb 2007-07-27 10:50:45 EDT
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
Comment 2 Borut Semenic 2007-07-27 11:23:38 EDT
Same here
Comment 3 Armijn Hemel 2007-07-27 16:01:11 EDT
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.
Comment 4 Christophe Lambin 2007-07-27 17:32:17 EDT
Same problem here. Even the following simple program shows the problem:
#include <stdio.h>
#include <time.h>

int main (int argc, char *argv[])
{
    time_t now = time(NULL);

    puts(ctime(&now));

    return 0;
}

Output is always:
$ ./ctime 
Sat Jul 28 00:44:40 2007
$ date
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. :-)
Comment 5 Kai Hambrecht 2007-07-27 17:43:51 EDT
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
2.6.22.1-33, while 2.6.22.1-27 just works fine.
Comment 6 Christophe Lambin 2007-07-27 18:51:53 EDT
Well, now that 'real time' has caught up with the 'fake time', the problem has
gone away:

$ ./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.
Comment 7 Peter Garcia-Webb 2007-07-27 20:27:04 EDT
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
happen"
Comment 8 Michael Weidner 2007-07-28 02:32:55 EDT
Same problem here ...
I wrote a little C-programm. The functions ctime, time and localtime do not work
correct.

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 (2.6.22.1-33.fc7) is not usable at all with this bug.

Back to 2.6.21-1.3228.fc7 (the last usable kernel for me).
Comment 9 Makoto Mizukami 2007-07-28 08:11:38 EDT
I was also knocked by the same issue.
According to my research, with "2.6.22.1-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 2.6.21.1-3228; the kernel that don't switch off ATA-HDD before
shutdown on my environment...
Comment 10 Vassilios Kotoulas 2007-07-28 08:59:44 EDT
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
Comment 11 Philippe Valembois 2007-07-28 09:15:09 EDT
It seems that KDE doesn't suffer of the bug...
Firefox neither (some JavaScript code to display time worked)...
The only workaround for now is to use kernel-2.6.22.1-27.fc7
Comment 12 Andreas M. Kirchwitz 2007-07-28 11:36:20 EDT
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.

Comment 13 Mihai Harpau 2007-07-28 11:51:09 EDT
kernel 2.6.22.1-41.fc7 from here
http://koji.fedoraproject.org/koji/buildinfo?buildID=12174 resolved this bug
Comment 14 Need Real Name 2007-07-29 00:35:22 EDT
*** Bug 249942 has been marked as a duplicate of this bug. ***
Comment 15 Need Real Name 2007-07-29 00:35:34 EDT
WFM
Comment 16 Peter Bieringer 2007-07-29 11:05:04 EDT
When would this kernel be pushed to update repository?
Comment 17 Ray Strode [halfline] 2007-07-30 09:49:24 EDT
*** Bug 250049 has been marked as a duplicate of this bug. ***
Comment 18 Chuck Ebbert 2007-07-30 09:49:42 EDT
*** Bug 249981 has been marked as a duplicate of this bug. ***
Comment 19 Kai Engert (:kaie) 2007-07-30 10:51:22 EDT
I guess this kernel had default priority, changing to "urgent". I agree
2.6.22.1-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.
Comment 20 Kai Engert (:kaie) 2007-07-30 10:56:01 EDT
(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
Comment 21 RR 2007-07-30 13:06:51 EDT
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?
Comment 22 Chuck Ebbert 2007-07-31 17:52:18 EDT
*** Bug 249878 has been marked as a duplicate of this bug. ***
Comment 23 Chuck Ebbert 2007-07-31 17:53:14 EDT
*** Bug 250066 has been marked as a duplicate of this bug. ***
Comment 24 Steven Bakker 2007-07-31 18:40:13 EDT
Kernel from comment 13 works and also fixes bug #249950 for me.
Comment 25 Peter Bieringer 2007-08-01 05:45:17 EDT
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
time.
Comment 26 Chuck Ebbert 2007-08-01 10:24:20 EDT
*** Bug 250373 has been marked as a duplicate of this bug. ***
Comment 27 Kai Engert (:kaie) 2007-08-03 09:10:12 EDT
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
for me.

Please comment or reopen the bug if you still have the problem.
Comment 28 Göran Uddeborg 2007-08-20 14:01:42 EDT
*** Bug 249918 has been marked as a duplicate of this bug. ***

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