Really could not say.

I have only seen this a couple of times before but (from what I can recall) never while booting*, I would have noticed it.
* Between [0.000000] and the end of the boot sequence. (see the time stamp on the dmesg printout)

And it is not reported by dmesg as a warning/alert/critical/error, so it is probably (?) harmless.

The BIOS (a POS if there ever was one) in my U24 WS does not have an entry for HPET and I certainly would not roll a kernel because of this.
More so if I cannot reproduce it or see any ill effects related to it.

Not to mention that I haven't a clue as to go about doing it. 8^°

My ca. 2007 U24 WS could be having this issue due to a less optimized HPET implementation, so it may be worthwhile attempting the tsc=nowatchdog kernel command line fix and wait to see what effect that has.

Thanks for your input.

Best,

A.

[SOLVED] clocksource: timekeeping watchdog on CPU1: acpi_pm wd-wd read
https://bbs.archlinux.org/viewtopic.php?id=278494

While checking my dmesg printout to see if I had properly fixed a damaged Palm data cable, I came across this bit:

--- snip ---
[20430.191148] clocksource: timekeeping watchdog on CPU3: hpet wd-wd read-back delay of 785435ns
[20430.191160] clocksource: wd-tsc-wd read-back delay of 209034ns, clock-skew test skipped!
--- snip ---

The printout does not say it is a warning (or alert/critical/error):

$ sudo dmesg --level=alert,crit,err,warn | grep timekeeping
$ 

I have also found that I can get the clocksource being used:

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
$

But I have not been able to find out what triggers it, its relevance or how it can be avoided.
It is a very small slice of time (0.001s ?) but there must be a reason for a timekeeping watchdog to let the system know there was a delay.

I'd appreciate input on this.

Best,

A.