dtrace: processing aborted: Abort due to systemic
unresponsiveness (dtrace_gethrtime()?) - and kgdb
Juergen Lock
nox at jelal.kn-bremen.de
Fri Oct 3 13:33:57 UTC 2008
On Wed, Sep 17, 2008 at 10:41:07PM +0200, I wrote:
> 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...
>
I since found out two things: a) the version of dtrace_gethrtime() in
sys/amd64/amd64/tsc.c is indeed not needed, and b) removing it still
didn't fix my problem, stopping powerd then did, even with the original
kernel. Doh! :)
Anyway, I'm still pretty sure the #ifdef KDTRACE_HOOKS code in
sys/amd64/amd64/tsc.c can go, the version of dtrace_gethrtime() in
sys/cddl/dev/dtrace/amd64/dtrace_subr.c looks more correct at least...
Thanx,
Juergen
More information about the freebsd-stable
mailing list