Re: Weird clock behaviour with current (amd64) kernel

[Masanobu SAITOH <msaitoh%execsw.org@localhost>]

On 2022/07/14 22:59, Robert Elz wrote:
> 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.

Could you show me the full dmesg with verbose output?
i.e. add -v option to the boot command in /boot.cfg.
It shows some message related to the TSC stuff.

Thanks in advance.


> 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

-- 
-----------------------------------------------
                SAITOH Masanobu (msaitoh%execsw.org@localhost
                                 msaitoh%netbsd.org@localhost)