> Date: Sun, 18 May 2025 00:25:32 +0000 > From: Emmanuel Dreyfus <m...@netbsd.org> > > On Sun, Apr 06, 2025 at 11:50:37PM +0000, Emmanuel Dreyfus wrote: > > I restarted with stock 10.0 XEN3_DOMU kernel to get dtrace working > > (it does not), but now the problem seems to have vanished. > > I have a domU carrying a busy web server. I upgraded vcpus from > 1 to 4, and the time keeping bug pops up within a few hours. > ntpd gets unable to keep in sync, and clock quickly drift. > > After 40 minutes of utpime, I already have toublesome outout from > the test counting how many time gettimefday() returns the same value. > Here is an example for 1000 calls: > 227 1747527666.919678 > 204 1747527666.919679 > [...]
Remind me -- are you running with or without the xenclock.patch I posted on 2025-04-05? I recall there was some trouble with dtrace at the time I posted it. https://mail-index.NetBSD.org/tech-kern/2025/04/05/msg030323.html If without, can you try running with and see if this still reproduces? And, if you built a kernel with options KDTRACE_HOOKS, can you share any output from the following dtrace script? (Will only print output when something bad happens.) dtrace -n 'sdt:xen:clock:, sdt:xen:timecounter:, sdt:xen:hardclock:systime-backward, sdt:xen:hardclock:jump, sdt:xen:hardclock:missed { printf("%d %d %d %d %d %d %d", arg0, arg1, arg2, arg3, arg4, arg5, arg6) }' Note: I do expect to see gettimeofday return the same result as the last call from time to time; on my laptop with a tsc frequency of 2.112 GHz, a call to gettimeofday usually takes between 1400 and 2700 TSC cycles, which is between 0.6us and 1.3us. Of course, not 227 consecutive repeats! Does clock_gettime(CLOCK_MONOTONIC, &t) also repeat itself?
