All:
So far, good news to report. 2.6.14rc5 compiled still has a 2x
clock speed, but adding notsc and no_timer_check (not sure if both are
necessary) to the boot seems to result in a system that has a clock with
reasonable integrity, without all the problems of noapic, etc.
I have seen apic errors, so far twice in kern.log:
Oct 22 20:52:44 line kernel: APIC error on CPU0: 40(40)
Oct 22 20:52:44 line kernel: APIC error on CPU1: 40(40)
Unfortunately 2 hours is not enough time to say this is a stable
configuration (24 hours is better), but encouraging. I have hit the
system with high cpu, video, disk, and ieee load to test but sometime
the clock starts going haywire again after several more hours...
Thanks to all that responded so far.
mikepolniak wrote:
On 11:35 Sat 22 Oct , Richard Mace wrote:
Nathan,
I can empathise. I have a two week old HP NX6125 notebook that also suffers
from the same problem. I think that you have identified the bug correctly as
#3927. I've just checked bugzilla.kernel.org/show_bug.cgi?id=3927 and the
status is ASSIGNED. The owner is Andi Kleen (at suse). As far as I can tell
there are some patches available, but none deemed "stable" enough to
incorporate into current kernels.
The ChangeLog-2.6.14-rc5 has this fix for TSC timers:
Author: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu Oct 13 14:41:44 2005 -0700
[NET]: Disable NET_SCH_CLK_CPU for SMP x86 hosts
Opterons with frequency scaling have fully unsynchronized TSCs
running at different frequencies, so using TSCs there is not a good idea.
Also some other x86 boxes have this problem. gettimeofday should be
good enough, so just disable it.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
I have had the 'lost ticks' problem with AMD x2 dual cpu and SMP. Now i
am running kernel-2.6.14-rc5 and the problem appears fixed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]