On 2020-03-10 01:38, Peter Jeremy wrote:
Are you running NTP? If so, is NTP maintaining lock and what is the
reported PLL frequency (ntpq -c kerni)?
Didn't show any useful difference, "kernel status: pll unsync" when I
tested this.
What does "sysctl kern.timecounter" report and have you tried using
any of the alternative timecounters listed in kern.timecounter.choice?
Indeed that reveals the problem:
kern.timecounter.hardware: TSC-low
(before regression)
kern.timecounter.tc.TSC-low.frequency: 1296053807
(after regression)
kern.timecounter.tc.TSC-low.frequency: 1300000000
(why are these tsc_freq divided by two?)
Through some printf's in tsc.c I've determined that the 2.6e9 value is
from 0x16 CPUID which Intel says is only a nominal value not to be used,
whereas 2.592e9 value is from calibration.
/*
* Calculate TSC frequency using information from the CPUID leaf 0x15
* 'Time Stamp Counter and Nominal Core Crystal Clock'. If leaf 0x15
* is not functional, as it is on Skylake/Kabylake, try 0x16 'Processor
* Frequency Information'. Leaf 0x16 is described in the SDM as
* informational only, but if 0x15 did not work, and TSC calibration
* is disabled, it is the best we can get at all. It should still be
* an improvement over the parsing of the CPU model name in
* tsc_freq_intel(), when available.
*/
The implementation logic for when to use tsc_freq_cpuid() looks wrong to
me; it doesn't match what this comment implies. Fallback to calibration
when calibration is unspecified should proceed when 0x15 fails
regardless of what 0x16 does. (CC'd the authors).
Switching to HPET or ACPI-fast gives the expected results. Would there
be any reason to not use HPET provided I can cope with the performance
implications?
The name of the ACPI option varies haphazardly between "ACPI-fast" and
"ACPI-safe" between reboots, I guess it is sensitive to some buggy
vendor firmware.
Are you overclocking your CPU (or doing anything else non-standard)?
I had previously used powerd to let the CPU underclock to 700MHz when
idle. Now, I've lost all control over CPU frequency (either by powerd
or by sysctl) since there is some in-kernel cpufreq driver which I can't
figure out how to disable. It's very much an annoyance, but I think
unrelated to the timecounter problem.
Theron
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
