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.

1 files changed, 3 insertions, 1 deletions

diff --git a/sys/arch/amd64/amd64/tsc.c b/sys/arch/amd64/amd64/tsc.c
index 238a5a068e1..93c9138d585 100644
--- a/sys/arch/amd64/amd64/tsc.c
+++ b/sys/arch/amd64/amd64/tsc.c
@@ -1,4 +1,4 @@
-/*	$OpenBSD: tsc.c,v 1.21 2020/09/06 20:50:00 cheloha Exp $	*/
+/*	$OpenBSD: tsc.c,v 1.22 2020/12/24 04:20:48 jsg Exp $	*/
 /*
  * Copyright (c) 2008 The NetBSD Foundation, Inc.
  * Copyright (c) 2016,2017 Reyk Floeter <reyk@openbsd.org>
@@ -72,6 +72,8 @@ tsc_freq_cpuid(struct cpu_info *ci)
 			case 0x5e: /* Skylake desktop */
 			case 0x8e: /* Kabylake mobile */
 			case 0x9e: /* Kabylake desktop */
+			case 0xa5: /* CML-H CML-S62 CML-S102 */
+			case 0xa6: /* CML-U62 */
 				khz = 24000; /* 24.0 MHz */
 				break;
 			case 0x5f: /* Atom Denverton */