Juergen Lock
2008-Sep-17 21:18 UTC
dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb
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.
Juergen Lock
2008-Oct-03 13:34 UTC
dtrace: processing aborted: Abort due to systemic unresponsiveness (dtrace_gethrtime()?) - and kgdb
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