Hi, I just booted a kernel that I built (from up to date at the time) HEAD sources about 24 hours ago.
Everything seemed to be working fine - until I noticed that all of my clocks (there are several, gkrellm, window manager, a dclock, and an xtu) were all wildly wrong (as in, were moving time forwards incredibly slowly). You can see the results of that if you compare the Date header, and Received header from my local system (jacaranda) with the Received header munnari adds (there should be no more than a second or two between those - in this message there will be much more). When I noticed this, I changed the clock source from TSC to hpet0, and since then, the system appears to be advancing time at about the right rate - but unlike its normal smooth motion, the second hand in xtu (the only one of the clocks that has seconds) looks very jerky, and ... jacaranda$ while sleep 1; do date; done Thu Jul 14 20:43:49 +07 2022 Thu Jul 14 20:43:52 +07 2022 Thu Jul 14 20:43:55 +07 2022 Thu Jul 14 20:43:58 +07 2022 Thu Jul 14 20:44:01 +07 2022 that would be much like what it looks like. This is a fairly normal kernel, the most notable features of its config are: options PCIVERBOSE # verbose PCI device autoconfig messages options PCI_CONFIG_DUMP # verbosely dump PCI config space options SCSIVERBOSE # human readable SCSI error messages options HDAUDIOVERBOSE # human readable HDAUDIO device names options ACPI_SCANPCI # find PCI roots using ACPI options MPBIOS # configure CPUs and APICs using MPBIOS options MPBIOS_SCANPCI # MPBIOS configures PCI roots options PCI_INTR_FIXUP # fixup PCI interrupt routing via ACPI options PCI_BUS_FIXUP # fixup PCI bus numbering options PCI_ADDR_FIXUP # fixup PCI I/O addresses options ACPI_ACTIVATE_DEV # If set, activate inactive devices options VGA_POST # in-kernel support for VGA POST options MSGBUFSIZE=1049600 (still not big enough to hold all of what PCI_CONFIG_DUMP produces, I do have the dmesg.boot file from it if anyone cares). Anyone have any ideas? Note that the CPU is an Alder Lake - has both performance and economy cores which run at different rates (which NetBSD knows nothing about, yet, but that's OK) - core speed is always subject to variation anyway, so that should not matter (and has not on previous kernels). My previous kernel did not have most of those options, and managed time well enough (I have never really trusted TSC, but it was at least close enough that NTP could keep it in line - this is beyond NTP's abilities). While I am here, an unrelatged matter, one other config option: options WS_KERNEL_FG=WSCOL_CYAN No way is that related to the time ... I've used that in kernels for decades. I mention it now, as it might just provide some assistance to those working on the graphics drivers. When the system first boots, all the console messages appear in yellow, not the normal green, and not cyan. After the system switches the console to graphics mode (it is an nvidia GT930 - running X on wsfb) the messages all switch to cyan. This harms nothing, it's just a bit weird, and I thought it might provide a clue to some possible setup errors? kre