CVSROOT: /cvs
Module name: src
Changes by: j...@cvs.openbsd.org 2020/12/23 21:20:48
Modified files:
sys/arch/amd64/amd64: tsc.c
Log message:
handle reported core clock frequency of 0 on newer Intel Comet Lake
The 'nominal core crystal clock frequency' from cpuid 0x15 is 0 on
Intel model 0xa5 (CML-H CML-S62 CML-S102) and 0xa6 (CML-U62). So act as
if 24 MHz was reported like we do on other Skylake/Kaby Lake variants.
Comet Lake processors with model 0x8e (CML-U42 CML-Y42) use the same model
number used by Kaby Lake and many other parts which was already handled.
While we could approximate the crystal frequency with 'Processor Base
Frequency' from cpuid 0x16 eax like FreeBSD and Linux do, kettenis@ couldn't
get ntpd to sync a clock on a Skylake machine with:
CPUID 0x15: eax=2, ebx=134, khz=0
CPUID 0x16: eax=1600, ebx=1600, ecx=100, edx=0
with reported crystal frequency changing from 24000 kHz to 23880 kHz
(cpuid 0x16 eax * 1000 * cpuid 0x15 eax / cpuid 0x15 ebx) and
TSC frequency changing from 1608000000 to 1599960000.
Cannon Lake, Ice Lake, and Tiger Lake are known to return non-zero
frequency in cpuid 0x15 so hopefully no other model ids have to be added.
James Cook reported hangs on bsd.rd with i7-10710U 06-a6-00 (CML-U62)
(which does not have acpihpet) but not with bsd.mp (which does) and has
confirmed that both approaches fixed the problem.
