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.
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.
Thanks,
tglx
