Weird clock behaviour with current (amd64) kernel

[Robert Elz <kre%munnari.OZ.AU@localhost>]

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