linux-kernel - Re: constant_tsc and TSC unstable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <474F2E97.5080802@msgid.tls.msk.ru>
Date:	Fri, 30 Nov 2007 00:26:47 +0300
From:	Michael Tokarev <mjt@....msk.ru>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	"Paul Rolland (ポール・ロラン)" 
	<rol@...be.net>, Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: constant_tsc and TSC unstable

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

> 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@...tus.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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/