On 05/15/2012 03:12 AM, Felix Miata wrote:
I wonder why the kernel is not marking the tsc as unreliable and switching to another clocksource automatically..hrmmm.
Sounds like a question for kernel people.
I saw something similar to this on several dell P4/2800->3400 boxes shortly after the release of the 3.0.X kernels. The real time clock on the boxes would drift off into the future by 8 hours in a 24-48 hour period. On these particular boxes, once the time difference exceeded 8 hours, a spontaneous reboot would be triggered. Here is a brief snippet from the logs of what I saw during October of last year: Oct 19 13:15:02 providence crond[955]: time disparity of 301 minutes detected Oct 18 12:42:00 providence crond[958]: time disparity of -479 minutes detected Oct 18 12:32:00 providence crond[1180]: time disparity of -479 minutes detected Oct 18 11:19:01 providence crond[978]: time disparity of -479 minutes detected Oct 18 09:44:01 providence crond[953]: time disparity of -478 minutes detected Oct 12 09:24:01 providence crond[942]: time disparity of -79 minutes detected Oct 7 10:55:59 providence crond[964]: time disparity of 253 minutes detected Oct 5 07:55:57 providence crond[921]: time disparity of 383 minutes detected Oct 3 16:23:01 providence crond[954]: time disparity of 301 minutes detected The problem seemed to be caused by the hwclock being set to LOCALTIME for dual boot. I never found a solution to the problem and ended up just setting the hwclock to UTC. There were no issues when set to UTC. However, there was another user that experienced a 360 min jump with the clock set to UTC. What I did uncover, was that at least for the Arch boxes, LOCALTIME is somewhat deprecated and can produce unpredictable results with new kernels. I don't know that this is related to what you were seeing, but these boxes have all run opensuse and arch for years and I had never experienced this type of clock drift before. I can go back and find out exactly which kernel it was from the mail archive, but the UTC setting eliminated the issue for me, so I haven't bothered to look further. This issue may also have been fixed in updates to the kernel in the past seven months as well. Another surprising thing was this seemed to affect these Dell boxes while other boxes continued to work. So it looked like it was a problem that was part kernel and part bios on those particular machines. Sorry no solutions, but maybe some info here that I'm not seeing might help. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org