Description of problem:
After updating to kernel-2.6.15-1.2032_FC5, I noticed that my system clock
started running WAY too fast. I gained an entire hour in about a day. (The
clock runs so fast it can't stay in sync with NTP servers.) My hardware clock
is perfectly fine. Rebooting to kernel-2.6.15-1.2009.4.2_FC5 makes it work
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot in that kernel
System clock runs way too fast
System clock runs normally
It works perfectly fine on the previous kernel, kernel-2.6.15-1.2009.4.2_FC5,
both before and after rebooting to it.
Problem persists on todays kernel-2.6.15-1.2038_FC5. Rebooting to
kernel-2.6.15-1.2009.4.2_FC5 again works fine. Any particular information that
would be helpful?
dmesg and dmidecode output please ?
Created attachment 125969 [details]
dmesg with kernel-2.6.15-1.2038_FC5 (clock too fast)
Created attachment 125970 [details]
dmidecode with kernel-2.6.15-1.2038_FC5
Created attachment 125971 [details]
dmesg with kernel-2.6.15-1.2009.4.2_FC5 (works)
I didn't enter the nolapic keyword but it seems like it was disabled by
Booting with 'noapic' makes it work fine. I can add another dmesg if it would help.
Looks like a duplicate of Bug #55223 albeit striking uni-processor
kernels, too, now. I had reopened Bug #55223 on 2006-03-05 after
observing the same regression which had occurred some time in
Seems to be working fine with kernel-2.6.16-1.2080_FC5 even without noapic. Thanks!
*** This bug has been marked as a duplicate of 55223 ***