On 2012/05/15 10:12 (GMT-0500) David C. Rankin composed:
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. ... 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 have a bunch of Dells with P4 CPUs, but the problem here is with a generic motherboard, though made by Foxconn, which was making motherboards for Dell around that time. Your 2800MHz were more likely Prescott, while 3400MHz more likely Cedar Mill. My problem is a 3400MHz Cedar Mill, though I haven't even looked for it on my 2800GHz or faster P4 Dells. The problem machine is the only one in the building not set to local time. Luckily, clock=hpet is an easy enough to live with solution via /etc/sysconfig/bootloader's DEFAULT_APPEND. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org