You are not logged in.
Hello:
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.
Last edited by Altoid (2025-07-04 17:37:23)
Offline
This any help?
[SOLVED] clocksource: timekeeping watchdog on CPU1: acpi_pm wd-wd read
https://bbs.archlinux.org/viewtopic.php?id=278494
Offline
Hello:
This any help?
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.
Offline