> Date: Mon, 31 Jul 2023 12:47:20 -0400
>
> # dtrace -x nolibs -n 'sdt:xen:hardclock:jump { @ = quantize(arg1 - arg0) }
> sdt:xen:hardclock:jump /arg2 >= 430/ { printf("hardclock jump violated
> timecounter contract") }'
> dtrace: description 'sdt:xen:hardclock:jump ' matched 2 probes
> dtrace: processing aborted: Abort due to systemic unresponsiveness
Well! dtrace might be unhappy if the timecounter is broken too, heh.
So I just added a printf to the kernel in case this jump happens. Can
you update to xen_clock.c 1.15 (and sys/arch/x86/include/cpu.h 1.135)
and try again?
> The system is fine just after a reboot, it certainly seems to be a
> requirment that a fair bit of work must be done before it gets into a
> bad state.
>
> If the dtrace does continue to run, sometimes, it is impossible to exit
> with CTRL-C. The process seems stuck in this:
>
> [ 4261.7158728] load: 2.64 cmd: dtrace 3295 [xclocv] 0.01u 0.02s 0% 7340k
Interesting. If this is reproducible, can you enter crash or ddb and
get a stack trace for the dtrace process, as well as output from ps,
ps/w, and `show all tstiles'?
