H. Peter Anvin wrote:
quoted text
> Paul Rolland (ポール・ロラン) wrote:
[]
quoted text
>> Measured 3978592228 cycles TSC warp between CPUs, turning off TSC clock.
>> Marking TSC unstable due to: check_tsc_sync_source failed.
[]
quoted text
>> but I was wondering if this is a bug or a feature ;)

quoted text
> The problem you're having is that the TSCs of your two cores are
> completely different, over a second apart.  This is a bug, unrelated to
> constant_tsc.

A bug in where - in the CPU or in kernel?

The thing is that all our dual-core machines shows something like
that.

For example, dualcore PentiumD machine:
Nov  7 20:23:56 paltus kernel: Linux version 2.6.22-i686smp (mjt@paltus.tls.msk.ru) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #2.6.22.12 SMP Wed Nov 7 20:02:14 MSK 2007
...
Nov  7 20:23:56 paltus kernel: checking TSC synchronization [CPU#0 -> CPU#1]:
Nov  7 20:23:56 paltus kernel: Measured 112 cycles TSC warp between CPUs, turning off TSC clock.
Nov  7 20:23:56 paltus kernel: Marking TSC unstable due to: check_tsc_sync_source failed.
Nov  7 20:23:56 paltus kernel: Brought up 2 CPUs

(not that huge difference as Paul reported, but still "unstable".
The same happens with 2.6.23)

Note that once TSC is disabled (it's using "jiffies" as far
as I can see), ntpd constantly speeds up and slows down the
clock, it jumps +/- 0.5sec every several minutes or hours -
I guess that's when ntpd process gets moved from one core
to another for whatever reason.  And an interesting thing
is that with 64bits kernel this TSC problem does not occur
on this very machine.

Something similar is reported on AMD X2 64 machines as well --
can't check right now.

Thanks.

/mjt
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/