On 2/26/20 6:27 PM, Thomas Gleixner wrote: > Peter Zijlstra <peterz@xxxxxxxxxxxxx> writes: >> On Wed, Feb 26, 2020 at 11:43:08AM -0500, Prarit Bhargava wrote: >>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt >>> index dbc22d684627..0316aadfff08 100644 >>> --- a/Documentation/admin-guide/kernel-parameters.txt >>> +++ b/Documentation/admin-guide/kernel-parameters.txt >>> @@ -4942,7 +4942,7 @@ >>> See Documentation/admin-guide/mm/transhuge.rst >>> for more details. >>> >>> - tsc= Disable clocksource stability checks for TSC. >>> + tsc=option[,option...] Various TSC options. >>> Format: <string> >>> [x86] reliable: mark tsc clocksource as reliable, this >>> disables clocksource verification at runtime, as well >>> @@ -4960,6 +4960,12 @@ >>> in situations with strict latency requirements (where >>> interruptions from clocksource watchdog are not >>> acceptable). >>> + [x86] no_cpuid_calibration: Disable the CPUID TSC >>> + calibration. Used in situations where the CPUID >>> + TSC khz does not match the actual CPU TSC khz >>> + [x86] no_msr_calibration: Disable the MSR TSC >>> + calibration. Used in situations where the MSR >>> + TSC khz does not match the actual CPU TSC khz. >> >> Do we want to mention that these situations are mostly broken firmware? >> Also do mention that if you disable these you might not boot due to not >> having a PIT/HPET at all? > > Right. Same discussion as before. > > Also why do we want no_cpuid_calibration and no_msr_calibration? How > should Joe User figure out which one to use? This does not make > sense. The point is that the BIOS/Firmware supplied value in system > registers is bogus. So something like "skip_firmware_calibration" might > be better suitable. no_cpuid_calibration was required for Patrick's case where the CPU was overclocked and therefore the CPUID khz value was invalid, but the MSR value is good. I had to skip both to get to the PIT calibration because I had broken FW. I don't see how a single skip_firmware_calibration covers these cases. > > Aside of that this really wants to be combined with the ability to > supply the actual frequency on the command line as I suggested in the > other thread to cope with machines which do not expose PIT/HPET or have > broken variants of them. tglx, can you give a lore link to the thread? Thanks, P. > > Thanks, > > tglx > >
