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 perfectly. Version-Release number of selected component (if applicable): kernel-2.6.15-1.2032_FC5 How reproducible: Every time Steps to Reproduce: 1. Boot in that kernel Actual results: System clock runs way too fast Expected results: System clock runs normally Additional info: 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 default.
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 January 2006.
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 ***