[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: fast clock wreaks havoc on amd64 dual core - hp1250n


   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 <ak@suse.de>
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 <ak@suse.de>

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.
Reply to: