> Date: Sun, 18 May 2025 18:49:51 +0000 > From: Emmanuel Dreyfus <m...@netbsd.org> > > On Sun, May 18, 2025 at 12:29:51PM +0000, Taylor R Campbell wrote: > > 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.) > > I built with KDTRACE_HOOKS, but dtrace still does not work. It fails > to load the dtrace module. Console says: > [ 8928.7630011] kobj_checksyms, 1013: [dtrace]: linker error: symbol > `dtrace_smap_enable' not found > [ 8928.7630011] kobj_checksyms, 1013: [dtrace]: linker error: symbol > `dtrace_smap_disable' not found > [ 8928.7630011] WARNING: module error: Unable to affix module `dtrace', error > 8
Please build with KDTRACE_HOOKS _and_ the patch I already sent you for this, which I haven't committed yet because I was waiting for your feedback on verifying it: https://mail-index.NetBSD.org/tech-kern/2025/04/06/msg030329.html > Perhaps we could just try a bunch of printfs? You can try defining XEN_CLOCK_DEBUG in xen_clock.c, but: 1. you have to rebuild your kernel every time you want to change this, whereas with dtrace you can gather vast swaths of information flexibly without rebuilding your kernel or even rebooting; and 2. I seem to recall reports that the printfs are so noisy on some machines that they overwhelm the serial console and make the system hang at boot. So it is absolutely worth the trouble to get dtrace working _now_ so that you can repeatedly use it for many future diagnostics.
