dtrace: processing aborted: Abort due to systemic unresponsiveness
(dtrace_gethrtime()?) - and kgdb
Juergen Lock
nox at jelal.kn-bremen.de
Wed Sep 17 21:18:32 UTC 2008
Hi!
I got curious in dtrace, and after mr's sys/amd64/amd64/trap.c
commit (r183050, thanx! :) I was able to build a kernel that could
kldload dtraceall on 7-stable amd64, but trying even simple things like
dtrace -n tick-1sec
only runs for a short time, or not at all, ending with $subject:
# dtrace -n tick-1sec
dtrace: description 'tick-1sec' matched 1 probe
dtrace: buffer size lowered to 2m
CPU ID FUNCTION:NAME
1 32125 :tick-1sec
dtrace: processing aborted: Abort due to systemic unresponsiveness
# dtrace -n tick-1sec
dtrace: description 'tick-1sec' matched 1 probe
dtrace: buffer size lowered to 2m
dtrace: processing aborted: Abort due to systemic unresponsiveness
#
Looking around on the net I find that this is probably related to
dtrace_gethrtime() (this box is SMP), which I see defined in
sys/amd64/amd64/tsc.c, but also in sys/cddl/dev/dtrace/amd64/dtrace_subr.c,
and in sys/cddl/dev/dtrace/i386/dtrace_subr.c, but nowhere under sys/i386.
The versions in sys/cddl/dev/dtrace take cpu-dependent tsc offsets into
account which the one in sys/amd64/amd64/tsc.c doesn't, is there any
particular reason this version is used? Also I don't see it in HEAD...
Wondering,
Juergen
PS: I also found out that kgdb doesn't seem to like dtrace bits in the
kernel, backtraces look like from a kernel without debug symbols, even
if I don't use dtrace or even kldload it.
More information about the freebsd-stable
mailing list