Clocksource messages in dmesg within a Linux VM. Is this something I need to fix?

[gouthamravee]

Hello! Because of another issue, I decided to check dmesg inside one of my VMs today and I saw a bunch of messages like this

[21128.737674] clocksource: wd-tsc-wd read-back delay of 129300ns, clock-skew test skipped!
[21463.754802] clocksource: timekeeping watchdog on CPU6: hpet wd-wd read-back delay of 74300ns
[21463.754818] clocksource: wd-tsc-wd read-back delay of 9637350ns, clock-skew test skipped!
[21971.233380] clocksource: timekeeping watchdog on CPU1: hpet wd-wd read-back delay of 67420ns
[21971.233440] clocksource: wd-tsc-wd read-back delay of 186990ns, clock-skew test skipped!

Some quickly googling lead me to a few forum posts that describe changing the tscboot parameter, but I'm not sure if this is something I need to do.

Some other bits of the log

[29260.737186] clocksource: timekeeping watchdog on CPU0: hpet wd-wd read-back delay of 73930ns
[29260.737237] clocksource: wd-tsc-wd read-back delay of 109340ns, clock-skew test skipped!
[29627.747161] clocksource: timekeeping watchdog on CPU14: hpet wd-wd read-back delay of 106290ns
[29627.747177] clocksource: wd-tsc-wd read-back delay of 2165710ns, clock-skew test skipped!
[29992.066532] perf: interrupt took too long (42196 > 42132), lowering kernel.perf_event_max_sample_rate to 4500

and I also see stuff like

[18534.241374] clocksource: timekeeping watchdog on CPU7: hpet wd-wd read-back delay of 57580ns
[18534.241385] clocksource: wd-tsc-wd read-back delay of 172600ns, clock-skew test skipped!
[18713.818339] sh[2603]: segfault at 7ffdb4145ff8 ip 00007f2f7a17b606 sp 00007ffdb4145ff0 error 6 in ld-musl-x86_64.so.1[7f2f7a13e000+4c000] likely on CPU 4 (core 4, socket 0)
[18713.818378] Code: 49 89 f8 49 8d 41 ff eb 07 31 c0 4c 8d 44 24 07 48 89 44 24 10 48 8d 7c 24 18 31 c0 b9 3a 00 00 00 f3 ab 48 8d 05 36 ff ff ff <4c> 89 44 24 08 48 89 44 24 60 48 8d 44 24 06 48 89 44 24 70 48 8d
[19031.745361] clocksource: timekeeping watchdog on CPU2: hpet wd-wd read-back delay of 64340ns

This is one of the posts I saw - https://bbs.archlinux.org/viewtopic.php?id=278494

The suggestion there is to either do tsc=unstable or tsc=nowatchdog.
I found more info about what tsc here - https://docs.redhat.com/en/document...l/9.4_release_notes/kernel_parameters_changes

What I don't understand is how the different options available for tsc apply to my situation. Based on the RHEL documentation it seems like tsc=reliable would be the better option since I am running this virtualized.

I found a few other posts that mention the same problem, and then say the solution is setting the tsc parameter, but no explaination beyond that.

Host details:
Proxmox version: pve-manager/8.4.1/2a5fa54a8503f96d
Linux version: Linux 6.8.12-9-pve (2025-03-16T19:18Z
CPU: Intel(R) Xeon(R) CPU E5-2650L v4
Motherboard: Asus X99-WS/IPMI

VM details:
OS: Dietpi, Linux
Kernel: 6.1.0-37-amd64
Purpose: Running Plex and a few related services using Docker.

 

[l.leahu-vladucu]

Hello gouthamravee!

Because of another issue,

Which issue did you have, if I may ask? I'm trying to understand whether your issues are related to each other.

Due to the tsc issues, I would recommend to check whether there are any BIOS and other firmware updates available and install them. Please note that you might have to reconfigure your BIOS settings after updating.

However...

[18713.818339] sh[2603]: segfault at 7ffdb4145ff8 ip 00007f2f7a17b606 sp 00007ffdb4145ff0 error 6 in ld-musl-x86_64.so.1[7f2f7a13e000+4c000] likely on CPU 4 (core 4, socket 0)
[18713.818378] Code: 49 89 f8 49 8d 41 ff eb 07 31 c0 4c 8d 44 24 07 48 89 44 24 10 48 8d 7c 24 18 31 c0 b9 3a 00 00 00 f3 ab 48 8d 05 36 ff ff ff <4c> 89 44 24 08 48 89 44 24 60 48 8d 44 24 06 48 89 44 24 70 48 8d

To be on the safe side, could you please also run memtest86+ and let it pass a few times?

 

[gouthamravee]

Which issue did you have, if I may ask? I'm trying to understand whether your issues are related to each other.

They're not, that's just my storytelling side adding unnecessary info for no reason, lol. The other problem was Nvidia drivers on the VM crashing, it was something related to the latest Nvidia drivers that was fixed by rolling back to a previous driver and adding this to the grub config nvidia.NVreg_EnableGpuFirmware=0.

Based on this - https://www.asus.com/us/supportonly/x99-wsipmi/helpdesk_bios/ I am running the latest BIOS.

To be on the safe side, could you please also run memtest86+ and let it pass a few times?

This is going to be difficult, the server has my NAS, media server, and my reverse proxy. The media server I don't care too much, but It's going to be hard to find some time to have the NAS and reverse proxy down to do a memtest.

I did run a full memtest about 2 months ago when I swapped some memory sticks around. No errors back then. Also, as of right now, about 90% of the system's ram is in use. I figure if there was a memory problem, it would be very obvious with most of the RAM being used. I could be wrong though.

Let me know if there's anything else I can check. Checking dmesg, I'm still seeing the same tsc related messages even from a few minutes ago.