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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 30 Nov 2007 07:59:32 +0100
From:	Paul Rolland (ポール・ロラン) <rol@...be.net>
To:	Michael Tokarev <mjt@....msk.ru>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>, rol@...be.net
Subject: Re: constant_tsc and TSC unstable

Hello,

On Fri, 30 Nov 2007 00:26:47 +0300
Michael Tokarev <mjt@....msk.ru> wrote:

> 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?
Good question !
 
> The thing is that all our dual-core machines shows something like
> that.
> 
> (not that huge difference as Paul reported, but still "unstable".
> The same happens with 2.6.23)
I've been checking my logs, and the difference is quite constant and
huge :
[root@tux log]# grep 'cycles TSC warp' messages*
messages:Nov 26 08:27:56 tux kernel: Measured 4078687691 cycles TSC warp between C
PUs, turning off TSC clock.
messages:Nov 26 17:21:21 tux kernel: Measured 3978592228 cycles TSC warp between C
PUs, turning off TSC clock.
messages.1:Nov 18 22:52:23 tux kernel: Measured 4063102940 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.1:Nov 19 07:19:02 tux kernel: Measured 4057192061 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.1:Nov 23 20:50:12 tux kernel: Measured 4064589321 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.2:Nov 12 08:06:44 tux kernel: Measured 4072130361 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.2:Nov 13 19:42:47 tux kernel: Measured 4049899451 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.2:Nov 17 09:27:22 tux kernel: Measured 4066629060 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.3:Nov  5 08:25:08 tux kernel: Measured 4086386109 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.3:Nov  8 13:07:08 tux kernel: Measured 4041945934 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.3:Nov  9 23:31:24 tux kernel: Measured 4092303059 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Oct 29 07:28:23 tux kernel: Measured 4096946373 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Oct 31 17:07:21 tux kernel: Measured 4046765372 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Oct 31 17:15:09 tux kernel: Measured 4039328228 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Oct 31 23:19:00 tux kernel: Measured 4069714246 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  1 20:33:02 tux kernel: Measured 4088199726 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  2 11:53:17 tux kernel: Measured 4079927527 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  3 09:37:16 tux kernel: Measured 4071112656 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  3 10:51:29 tux kernel: Measured 3986266219 cycles TSC warp between
 CPUs, turning off TSC clock.
messages.4:Nov  4 18:14:56 tux kernel: Measured 4074214144 cycles TSC warp between
 CPUs, turning off TSC clock.

> 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.
Hmmmm.... That could make it a problem related to kernel rather than CPU.
 
> Something similar is reported on AMD X2 64 machines as well --
> can't check right now.
If I recall correctly, issues with AMD X2 where related to TSC being
independant for each core and not constant (speed depending of C state).
But the reason I raise the issue is that the Core2 reports constant TSC,
so there is (IMHO) no reason for that.

Paul

-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ