android_kernel_xiaomi_sm8350/arch/x86
Thomas Gleixner fbb16e2438 [x86] Fix TSC calibration issues
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@lwfinger.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-09-02 20:35:56 -07:00
..
boot x86: fix build warnings in real mode code 2008-08-18 09:20:14 +02:00
configs x86: update defconfigs 2008-08-27 08:14:17 +02:00
crypto
ia32 tracehook: exec 2008-07-26 12:00:08 -07:00
kernel [x86] Fix TSC calibration issues 2008-09-02 20:35:56 -07:00
kvm KVM: MMU: Fix torn shadow pte 2008-08-25 17:24:27 +03:00
lguest lguest: set max_pfn_mapped, growl loudly at Yinghai Lu 2008-07-29 09:58:31 +10:00
lib x86: msr: propagate errors from smp_call_function_single() 2008-08-25 17:45:48 -07:00
mach-default
mach-es7000
mach-generic
mach-rdc321x removed unused #include <linux/version.h>'s 2008-08-23 12:14:12 -07:00
mach-voyager
math-emu
mm x86: fix two modpost warnings in mm/init_64.c 2008-08-22 07:51:54 +02:00
oprofile x86: fix oprofile + hibernation badness 2008-08-20 16:18:31 +02:00
pci Un-break printk strings in x86 PCI probing code 2008-09-02 10:38:28 -07:00
power x86: fix i486 suspend to disk CR4 oops 2008-08-18 08:50:19 +02:00
vdso
video
xen
Kconfig [x86] Clean up MAXSMP Kconfig, and limit NR_CPUS to 512 2008-08-25 14:15:38 -07:00
Kconfig.cpu
Kconfig.debug
Makefile
Makefile_32.cpu