At Thu, 22 May 2025 16:22:43 -0700, "Greg A. Woods" <woods%planix.ca@localhost> wrote: Subject: Re: CVS commit: src/sys/arch/xen/xen > > We'll know in a week if it fixes anything. Sadly it didn't really fix anything. Time still goes wonky, here somewhat before 650,000 seconds uptime: [Fri May 30 03:31:34 2025][ 646993.1938510] xen_rtc_set: Setting to 1748601093.332013000 s at systime 647006841230263 ns, gst 646966565398370 ns (nanouptime: 646993193850970 ns, initial: 13647379293 ns) diff(gst-(nt+init)): -40.275831893 s [Fri May 30 03:31:45 2025][ 647004.1835228] xen_rtc_set: Setting to 1748601104.321685000 s at systime 647017830902126 ns, gst 646977554393322 ns (nanouptime: 647004183522833 ns, initial: 13647379293 ns) diff(gst-(nt+init)): -40.276508804 s [Fri May 30 03:31:56 2025][ 647015.1731999] xen_rtc_set: Setting to 1748601115.311362000 s at systime 647028820579202 ns, gst 646988543625304 ns (nanouptime: 647015173199909 ns, initial: 13647379293 ns) diff(gst-(nt+init)): -40.276953898 s [Fri May 30 03:32:07 2025][ 647025.1648753] xen_rtc_set: Setting to 1748601125.303037000 s at systime 647038812254578 ns, gst 646999534435018 ns (nanouptime: 647025164875285 ns, initial: 13647379293 ns) diff(gst-(nt+init)): -39.277819560 s [Fri May 30 03:32:17 2025][ 647026.1644901] xen_rtc_set: Setting to 1748601126.302652000 s at systime 647039811869421 ns, gst 647009533390743 ns (nanouptime: 647026164490128 ns, initial: 13647379293 ns) diff(gst-(nt+init)): -30.278478678 s [Fri May 30 03:32:26 2025](XEN) [2025-05-30 10:31:44.726] Watchdog timer fired for domain 0 [Fri May 30 03:32:26 2025](XEN) [2025-05-30 10:31:44.726] Hardware Dom0 shutdown: watchdog rebooting machine There are also still lots of event counters firing at what I think are excessive rates: # vmstat -e | fgrep xen | fgrep -v xenev0 vcpu0 xen missed hardclock 118751769 969 intr vcpu0 xen local_ns one tick or more behind global_ns 127585891 1041 intr vcpu0 xen global_ns prevented from running backwards 128939054 1052 intr vcpu1 xen missed hardclock 88227613 720 intr vcpu1 xen local_ns one tick or more behind global_ns 25709199 209 intr vcpu1 xen global_ns prevented from running backwards 36421443 297 intr vcpu2 xen missed hardclock 106878886 872 intr vcpu2 xen local_ns one tick or more behind global_ns 14847880 121 intr vcpu2 xen global_ns prevented from running backwards 18676556 152 intr vcpu3 xen missed hardclock 106876926 872 intr vcpu3 xen local_ns one tick or more behind global_ns 14090038 115 intr vcpu3 xen global_ns prevented from running backwards 18005325 147 intr vcpu4 xen missed hardclock 63950 0 intr vcpu4 xen global_ns prevented from running backwards 79344978 647 intr vcpu5 xen missed hardclock 71467 0 intr vcpu5 xen global_ns prevented from running backwards 124023990 1012 intr vcpu6 xen missed hardclock 61283 0 intr vcpu6 xen global_ns prevented from running backwards 34744740 283 intr vcpu7 xen missed hardclock 63656 0 intr vcpu7 xen global_ns prevented from running backwards 20660958 168 intr I do think that while it was running OK that there might have been slightly less wandering skew in the global system time, but that's just a feeling, not based on any solid measurements or stats. So, I think the change is good, though maybe not necessary, and it clearly doesn't fix or work around the underlying Xen kernel problem. -- Greg A. Woods <gwoods%acm.org@localhost> Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost> Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgp8g4UHy21Ij.pgp
Description: OpenPGP Digital Signature