linux-kernel - Re: [PATCH] Fix TSC calibration issues

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]

Date:	Tue, 02 Sep 2008 21:51:34 -0500
From:	Larry Finger <Larry.Finger@...inger.net>
To:	Thomas Gleixner <tglx@...utronix.de>
CC:	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Alok Kataria <akataria@...are.com>,
	Michael Buesch <mb@...sch.de>
Subject: Re: [PATCH] Fix TSC calibration issues

Thomas Gleixner wrote:
> Larry Finger reported at http://lkml.org/lkml/2008/9/1/90:
> An ancient laptop of mine started throwing errors from b43legacy when
> I started using 2.6.27 on it. This has been bisected to commit bfc0f59
> "x86: merge tsc calibration".
> 
> The unification of the TSC code adopted mostly the 64bit code, which
> prefers PMTIMER/HPET over the PIT calibration.
> 
> Larrys system has an AMD K6 CPU. Such systems are known to have
> PMTIMER incarnations which run at double speed. This results in a
> miscalibration of the TSC by factor 0.5. So the resulting calibrated
> CPU/TSC speed is half of the real CPU speed, which means that the TSC
> based delay loop will run half the time it should run. That might
> explain why the b43legacy driver went berserk.
> 
> On the other hand we know about systems, where the PIT based
> calibration results in random crap due to heavy SMI/SMM
> disturbance. On those systems the PMTIMER/HPET based calibration logic
> with SMI detection shows better results.
> 
> According to Alok also virtualized systems suffer from the PIT
> calibration method.
> 
> The solution is to use a more wreckage aware aproach than the current
> either/or decision.
> 
> 1) reimplement the retry loop which was dropped from the 32bit code
> during the merge. It repeats the calibration and selects the lowest
> frequency value as this is probably the closest estimate to the real
> frequency
> 
> 2) Monitor the delta of the TSC values in the delay loop which waits
> for the PIT counter to reach zero. If the maximum value is
> significantly different from the minimum, then we have a pretty safe
> indicator that the loop was disturbed by an SMI.
> 
> 3) keep the pmtimer/hpet reference as a backup solution for systems
> where the SMI disturbance is a permanent point of failure for PIT
> based calibration
> 
> 4) do the loop iteration for both methods, record the lowest value and
> decide after all iterations finished.
> 
> 5) Set a clear preference to PIT based calibration when the result
> makes sense.
> 
> The implementation does the reference calibration based on
> HPET/PMTIMER around the delay, which is necessary for the PIT anyway,
> but keeps separate TSC values to ensure the "independency" of the
> resulting calibration values.
> 
> Tested on various 32bit/64bit machines including Geode 266Mhz, AMD K6
> (affected machine with a double speed pmtimer which I grabbed out of
> the dump), Pentium class machines and AMD/Intel 64 bit boxen.
> 
> Bisected-by:  Larry Finger <Larry.Finger@...inger.net>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> ---

I know that Linus has some problems with this patch, but FWIW it 
worked on my K6. The dmesg output is

TSC: PIT calibration deviates from PMTIMER: 428809 214401.
TSC: Using PIT calibration value
Detected 428.809 MHz processor.

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