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: <1274727116.2954.5.camel@localhost.localdomain>
Date:	Mon, 24 May 2010 11:51:56 -0700
From:	john stultz <johnstul@...ibm.com>
To:	Dan Magenheimer <dan.magenheimer@...cle.com>
Cc:	Brian Bloniarz <bmb@...enacr.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andi Kleen <andi@...stfloor.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Venkatesh Pallipadi <venki@...gle.com>, chris.mason@...cle.com,
	linux-kernel@...r.kernel.org
Subject: RE: [PATCH] x86: Export tsc related information in sysfs

On Mon, 2010-05-24 at 11:13 -0700, Dan Magenheimer wrote:
> > From: john stultz [mailto:johnstul@...ibm.com]
> > 
> > Yea, the relative instability of the tsc calibration at boot is an
> > issue for folks who want very very precise timekeeping immediately
> > after a reboot.
> > 
> > I proposed a solution to this awhile back via a boot option users
> > could use to specify the tsc_khz freq, so it would be consistent from
> > boot to boot. See: https://patchwork.kernel.org/patch/22492/
> > 
> > It didn't really go anywhere due to a lack of public interest.
> > However, if you're interested in playing with it, I can try to revive
> > the patch.
> 
> Another possibility: Optionally trust the stamped rate for the part?
> 
> I understand that on Nehalem this value is available in
> MSR_PLATFORM_INFO[15:8] (google for MSR_PLATFORM_INFO 15 8),
> but I don't know if this MSR is available on older (or AMD)
> processors.

Hmmm. That could be an option for newer cpus that I wouldn't oppose.

While Peter is correct that the stamped value is probably not very
accurate, atleast it would be constant from boot to boot, and NTP's
calculated drift value would be correct. 

We'd need a check to make sure its not way off, since NTP will give up
if its outside 500ppm.  So as long as its close to the calibrated value,
we probably could use it.

thanks
-john


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