From the DTrace manual The arguments to profile probes are as follows: arg0 The program counter (PC) in the kernel at the time that the probe fired, or 0 if the current process was not executing in the kernel at the time that the probe fired arg1 The PC in the user-level process at the time that the probe fired, or 0 if the current process was executing at the kernel at the time that the probe fired As the descriptions imply, if arg0 is non-zero then arg1 is zero; if arg0 is zero then arg1 is non-zero. Thus, you can use arg0 and arg1 to differentiate user-level from kernel level, as in this simple example: profile-1ms { @ticks[arg0 ? "kernel" : "user"] = count(); } This also fails the t_dtrace_contrib:tst_argtest_d test
What failure are you seeing? Both arguments 0? Both non-zero? Is it reproducible? The test consistently passes for me on amd64.
They're both always 0 (arg0 and arg1) at least in my tests on HEAD.
Could you verify that curthread->td_intr_frame is non-NULL in a tick-1s probe? The profile/tick providers use td_intr_frame to get the probe arguments, and this only works if C_DIRECT_EXEC is honoured by the callout subsystem.
dtrace -n 'tick-1 { printf("%d, %d", arg0, arg1); print(curthread->td_intr_frame);}' dtrace: description 'tick-1 ' matched 1 probe CPU ID FUNCTION:NAME 0 59045 :tick-1 0, 0struct trapframe * 0
I'm not able to reproduce this on 13-CURRENT. r318319 may have fixed the problem in question. If it's still an issue, please reopen. In that case please also describe the hardware used, and provide stack() output from a probe exhibiting the problem.