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