DTrace/FreeBSD source snapshot
John Birrell
Here is a link to a current snapshot containing DTrace:
<http://people.freebsd.org/~jb/dtrace/dtrace-20080201.tar.bz>
It's a big file, but for anyone who is interested, I can provide
diffs in future from it.
The source builds like a normal FreeBSD buildworld/buildkernel.
If you want debug symbols built in, you must do it by setting
DEBUG_FLAGS=-g in /etc/make.conf. Just trying to set the default
CFLAGS to include -g won't work because the CTF tools (which
create the CTF ELF segment that DTrace uses) will compile with
-g anyway, and only if you have set DEBUG_FLAGS=-g will it leave
the debug ELF sections, otherwise they will be deleted as part
of the conversion.
A "make universe" will work across all architectures. The machine
dependent support for the kernel modules is only present for
amd64 and i386. i386 needs more asm code to support the exceptions
that the Function Boundary Trace (fbt) provider uses.
The DTrace Test Suite can be run:
cd src/tools/test/dtrace
make cleandir && make obj && make all
On amd64 all 822 tests should pass. Beware of the stress that some
of the tests place the system under. It is best to avoid running too
many other resource hungry apps at the same time. Also consider
the likelihood of the system locking up. This is Alpha quality. :-)
You can read the DTrace documentation online here:
<http://docs.sun.com/app/docs/doc/817-6223>
or you download the PDF file from there too.
You can load the DTrace kernel modules from the bootloader. There
are menu uptions for both single- and multi-user mode there.
Alternately you can "kldload dtraceall" to load the full DTrace
kernel module set.
With the modules loaded, you are ready to run the (superuser) "dtrace"
command line program.... see the documentation.
Enjoy.
--
John Birrell
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Andrew Gallatin
John Birrell writes:
> [ amd64 and i386 users only ]
>
> Here is a link to a current snapshot containing DTrace:
>
> <http://people.freebsd.org/~jb/dtrace/dtrace-20080201.tar.bz>
Awesome!
> It's a big file, but for anyone who is interested, I can provide
> diffs in future from it.
>
> The source builds like a normal FreeBSD buildworld/buildkernel.
A make -j16 buildworld using this tree died like as follows on
a virgin box, so it seems there may be some dependancy issues
to work out:
cc -O2 -fno-strict-aliasing -pipe -DHAVE_CONFIG_H
-I/var/tmp/dtrace/src/kerberos5/tools/make-roken/../../include -g -c
make-roken.c
ctfconvert -L VERSION make-print-version.o
ctfconvert: not found
*** Error code 127
1 error
*** Error code 2
ctfconvert -L VERSION make-roken.o
ctfconvert: not found
*** Error code 127
1 error
*** Error code 2
2 errors
I'll install ctfconvert and try again :)
Drew
Andrew Gallatin
Andrew Pogrebennyk writes:
> Andrew,
>
> I had to do "make world" first so that all OpenSolaris tools like
> ctfconvert would be installed. The world installed cleanly for me. But
> note that for there is -Werror defined in /usr/src/sys/conf/kmod.mk, all
> warnings are considered as errors and this potentially leads to troubles
> during kernel compilation.
>
> First error during kernel module compilation that I came across was
> about wrong format specifier:
> In function 'dtrace_ioctl':
> /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/dtrace_ioctl.c:294:
> warning: format '%zd' expects type 'signed size_t', but argument 4 has
> type 'uint64_t'
> *** Error code 1
I'm on amd64, so I did not see these warnings :)
BTW, if you forget options KTDTRACE_HOOKS, and try to
preload dtraceall, things explode rather spectacularly:
OK load dtraceall
/boot/kernel/dtraceall.ko size 0x2370 at 0xbcd000
loading required module 'cyclic'
/boot/kernel/cyclic.ko size 0x94c8 at 0xbd0000
<....>
OK boot
GDB: no debug ports present
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2008 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
1994
The Regents of the University of California. All rights
reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-CURRENT #0: Fri Feb 1 13:35:34 PST 2008
root@diablo2:/usr/obj/var/tmp/dtrace/src/sys/DIABLO
link_elf_obj: symbol lapic_cyclic_clock_func undefined
KLD file cyclic.ko - could not finalize loading
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x10
fault code = supervisor read data, page not present
instruction pointer = 0x8:0xffffffff8047e9b0
stack pointer = 0x10:0xffffffff80d14c80
frame pointer = 0x10:0xffffffff80d14d10
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 0 ()
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x17d
trap_fatal() at trap_fatal+0x29b
trap_pfault() at trap_pfault+0x294
trap() at trap+0x2f9
calltrap() at calltrap+0x8
--- trap 0xc, rip = 0xffffffff8047e9b0, rsp = 0xffffffff80d14c80, rbp
= 0xffffffff80d14d10 ---
linker_preload() at linker_preload+0x3f0
mi_startup() at mi_startup+0x59
btext() at btext+0x2c
kernel trap 12 with interrupts disabled
<repeating traps forever>
I then rebuilt with KDTRACE_HOOKS. This time, I had
another missing symbol (syscallnames). I'm about out of time
for today..
Drew
John Birrell
> A make -j16 buildworld using this tree died like as follows on
> a virgin box, so it seems there may be some dependancy issues
> to work out:
>
> cc -O2 -fno-strict-aliasing -pipe -DHAVE_CONFIG_H
> -I/var/tmp/dtrace/src/kerberos5/tools/make-roken/../../include -g -c
> make-roken.c
> ctfconvert -L VERSION make-print-version.o
> ctfconvert: not found
> *** Error code 127
I suggest building without -j16 for now. It should use the ctfconvert
built as a buildtool. I must need something more to tell make not
to get ahead of itself.
Also, there are a couple of references to SMP_MAXCPU which need to be
changed to MAXCPU. I missed those. Oops.
Andrew Pogrebennyk
> Andrew Pogrebennyk writes:
> > In function 'dtrace_ioctl':
> > /usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/dtrace_ioctl.c:294:
> > warning: format '%zd' expects type 'signed size_t', but argument 4 has
> > type 'uint64_t'
> > *** Error code 1
>
> I'm on amd64, so I did not see these warnings :)
>
> BTW, if you forget options KTDTRACE_HOOKS, and try to
> preload dtraceall, things explode rather spectacularly:
>
>
> <repeating traps forever>
>
>
> I then rebuilt with KDTRACE_HOOKS. This time, I had
> another missing symbol (syscallnames). I'm about out of time
> for today..
>
> Drew
OK, thanks for interesting info. However I got stuck with kernel module
compilation. There were two minor discrepancies between
/usr/src/sys/cddl/dev/dtrace/i386/dtrace_subr.c and
/usr/src/sys/sys/dtrace_bsd.h (different types if declaration and
definition of dtrace_trap() function and missing declaration of
dtrace_sync_func()). I solved that and now it complains on the word
"type" in dtrace_trap():
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386/dtrace_subr.c:
In function 'dtrace_trap':
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386/dtrace_subr.c:438:
error: 'type' undeclared (first use in this function)
Indeed, where it should be taken from?
/* Function to handle DTrace traps during probes. See i386/i386/trap.c */
int
dtrace_trap(struct trapframe *frame)
{
/*
* A trap can occur while DTrace executes a probe. Before
* executing the probe, DTrace blocks re-scheduling and sets
* a flag in it's per-cpu flags to indicate that it doesn't
* want to fault. On returning from the the probe, the no-fault
* flag is cleared and finally re-scheduling is enabled.
*
* Check if DTrace has enabled 'no-fault' mode:
*
*/
if ((cpu_core[curcpu].cpuc_dtrace_flags & CPU_DTRACE_NOFAULT)
!= 0) {
/*
* There are only a couple of trap types that are expected.
* All the rest will be handled in the usual way.
*/
switch (type) {
/* General protection fault. */
case T_PROTFLT:
/* Flag an illegal operation. */
[...]
--
Sincerely,
Andrew Pogrebennyk
Andrew Pogrebennyk
cc -O2 -fno-strict-aliasing -pipe -march=pentium4 -DDIS_MEM -DSMP
-DDEBUG -D_KERNEL -DKLD_MODULE -std=c99 -nostdinc
-I/usr/src/sys/modules/dtrace/dtrace/../../../compat/opensolaris
-I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace
-I/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386
-I/usr/src/sys/modules/dtrace/dtrace/../../../contrib/opensolaris/uts/common
-I/usr/src/sys/modules/dtrace/dtrace/../../..
-DHAVE_KERNEL_OPTION_HEADERS -include
/usr/obj/usr/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq
-finline-limit=8000 --param inline-unit-growth=100 --param
large-function-growth=1000 -fno-common -g -I/usr/obj/usr/src/sys/GENERIC
-mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
-Wno-pointer-sign -fformat-extensions -Wno-unknown-pragmas -c
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386/dtrace_subr.c
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386/dtrace_subr.c:
In function 'dtrace_trap':
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386/dtrace_subr.c:448:
error: dereferencing pointer to incomplete type
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386/dtrace_subr.c:448:
error: dereferencing pointer to incomplete type
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386/dtrace_subr.c:460:
error: dereferencing pointer to incomplete type
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/i386/dtrace_subr.c:460:
error: dereferencing pointer to incomplete type
*** Error code 1
In these lines we are trying to case pointer to struct trapframe to
pointer to u_char like:
frame->tf_eip += dtrace_instr_size((u_char *) frame->tf_eip);
What do i do to get it to work?
--
Sincerely,
Andrew Pogrebennyk
Andrew Gallatin
John Birrell writes:
> On Fri, Feb 01, 2008 at 04:17:40PM -0500, Andrew Gallatin wrote:
> > A make -j16 buildworld using this tree died like as follows on
> > a virgin box, so it seems there may be some dependancy issues
> > to work out:
> >
> > cc -O2 -fno-strict-aliasing -pipe -DHAVE_CONFIG_H
> > -I/var/tmp/dtrace/src/kerberos5/tools/make-roken/../../include -g -c
> > make-roken.c
> > ctfconvert -L VERSION make-print-version.o
> > ctfconvert: not found
> > *** Error code 127
>
> I suggest building without -j16 for now. It should use the ctfconvert
> built as a buildtool. I must need something more to tell make not
> to get ahead of itself.
I was excited to try it, I had an 8-way 1.8Ghz opteron, and I had less
than an hour to work with. :)
>
> Also, there are a couple of references to SMP_MAXCPU which need to be
> changed to MAXCPU. I missed those. Oops.
My panic-on-boot seems to have been caused by syscallnames[]
being missing because I'm not running witness/invarients.
I've attached a patch. I've not yet had time to try it.
Drew
John Birrell
Content-Description: message body text
> My panic-on-boot seems to have been caused by syscallnames[]
> being missing because I'm not running witness/invarients.
> I've attached a patch. I've not yet had time to try it.
Oh that explains it. I've seen that on releng7. I'll update
the current version.
Without the KDTRACE_HOOKS option, the modules should fail to
load via kldload. I guess that checking isn't possible if the
modules are loaded from boot.
BTW, as a committer it might be more convenient for you to use
the sources direct from the perforce server in
//depot/projects/dtrace.
John Birrell
> In these lines we are trying to case pointer to struct trapframe to
> pointer to u_char like:
> frame->tf_eip += dtrace_instr_size((u_char *) frame->tf_eip);
> What do i do to get it to work?
Looks like I'm missing:
#include <machine/frame.h>
--
John Birrell
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Peter Jeremy
>[ amd64 and i386 users only ]
>
>Here is a link to a current snapshot containing DTrace:
>
><http://people.freebsd.org/~jb/dtrace/dtrace-20080201.tar.bz>
>
>It's a big file, but for anyone who is interested, I can provide
>diffs in future from it.
>
>The source builds like a normal FreeBSD buildworld/buildkernel.
buildworld worked for me but buildkernel blew up:
--------------------------------------------------------------
>>> stage 2.3: build tools
--------------------------------------------------------------
cd /usr/obj/back/dtrace/src/sys/server; MAKESRCPATH=/back/dtrace/src/sys/dev/ai
c7xxx/aicasm make -DNO_CPU_CFLAGS -f /back/dtrace/src/sys/dev/aic7xxx/aicasm/Ma
kefile
Warning: Object directory not changed from original /var/obj/back/dtrace/src/sys
/server
yacc -b aicasm_gram -d -o aicasm_gram.c /back/dtrace/src/sys/dev/aic7xxx/aicasm
/aicasm_gram.y
yacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c /back/dtrace/src/sys/d
ev/aic7xxx/aicasm/aicasm_macro_gram.y
cc -O2 -fno-strict-aliasing -pipe -nostdinc -I/usr/include -I. -I/back/dtrace/sr
c/sys/dev/aic7xxx/aicasm -g -c /back/dtrace/src/sys/dev/aic7xxx/aicasm/aicasm.c
ctfconvert -L VERSION aicasm.o
ctfconvert:No such file or directory
*** Error code 1
Stop in /var/obj/back/dtrace/src/sys/server.
*** Error code 1
Stop in /back/dtrace/src.
*** Error code 1
Stop in /back/dtrace/src.
make buildkernel 26.60s user 12.64s system 52% cpu 1:14.80 total
server% find . /var/obj/back/dtrace/ -name ctfconvert
./cddl/usr.bin/ctfconvert
/var/obj/back/dtrace/src/tmp/legacy/usr/bin/ctfconvert
/var/obj/back/dtrace/src/tmp/back/dtrace/src/cddl/usr.bin/ctfconvert
/var/obj/back/dtrace/src/tmp/back/dtrace/src/cddl/usr.bin/ctfconvert/ctfconvert
/var/obj/back/dtrace/src/cddl/usr.bin/ctfconvert
/var/obj/back/dtrace/src/cddl/usr.bin/ctfconvert/ctfconvert
server%
I'm not sure why it's trying to run ctfconvert on aicasm since that's
solely a build tool (which is never installed) but if it's necessary
then this looks like an issue with the PATH being used in ${MAKE}. I
will investigate further when I have more time.
--
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
John Birrell
> buildworld worked for me but buildkernel blew up:
>
> --------------------------------------------------------------
> >>> stage 2.3: build tools
> --------------------------------------------------------------
> cd /usr/obj/back/dtrace/src/sys/server; MAKESRCPATH=/back/dtrace/src/sys/dev/ai
> c7xxx/aicasm make -DNO_CPU_CFLAGS -f /back/dtrace/src/sys/dev/aic7xxx/aicasm/Ma
> kefile
> Warning: Object directory not changed from original /var/obj/back/dtrace/src/sys
> /server
> yacc -b aicasm_gram -d -o aicasm_gram.c /back/dtrace/src/sys/dev/aic7xxx/aicasm
> /aicasm_gram.y
> yacc -b aicasm_macro_gram -p mm -d -o aicasm_macro_gram.c /back/dtrace/src/sys/d
> ev/aic7xxx/aicasm/aicasm_macro_gram.y
> cc -O2 -fno-strict-aliasing -pipe -nostdinc -I/usr/include -I. -I/back/dtrace/sr
> c/sys/dev/aic7xxx/aicasm -g -c /back/dtrace/src/sys/dev/aic7xxx/aicasm/aicasm.c
> ctfconvert -L VERSION aicasm.o
> ctfconvert:No such file or directory
It looks like the kernel build tools step must be missing
a NO_CTF=1 in it's make environment.
John Birrell
> Are there no anonymous checkouts from perforce?
Anonymous access to perforce isn't possible because perforce
maintains client state on the server. That's one of the
disadvantages of perforce.
> I remember looking a while ago and not finding anything. I also
> remember a cvsup server linked to it at some point..
There was, but some hardware problems got in the way of the
export and the files weren't kept up-to-date. Since I am so
close to committing to current, it isn't worth wasting the
project admins' time getting it back up an running when it
will be obsolete soon.
I decide that I could distribute one big tar and then diffs from
that, so although the initial download is huge, keeping the
source tree up-to-date should be just a matter of applying a
patch or two (or twenty).
Thomas Hurst
> BTW, as a committer it might be more convenient for you to use the
> sources direct from the perforce server in //depot/projects/dtrace.
Are there no anonymous checkouts from perforce? I remember looking a
while ago and not finding anything. I also remember a cvsup server
linked to it at some point..
--
Thomas 'Freaky' Hurst
http://hur.st/
Alexandre "Sunny" Kovalenko
On Fri, 2008-02-01 at 22:37 +0000, John Birrell wrote:
> On Fri, Feb 01, 2008 at 04:17:40PM -0500, Andrew Gallatin wrote:
> > A make -j16 buildworld using this tree died like as follows on
> > a virgin box, so it seems there may be some dependancy issues
> > to work out:
> >
> > cc -O2 -fno-strict-aliasing -pipe -DHAVE_CONFIG_H
> > -I/var/tmp/dtrace/src/kerberos5/tools/make-roken/../../include -g -c
> > make-roken.c
> > ctfconvert -L VERSION make-print-version.o
> > ctfconvert: not found
> > *** Error code 127
>
> I suggest building without -j16 for now. It should use the ctfconvert
> built as a buildtool. I must need something more to tell make not
> to get ahead of itself.
>
>
> Also, there are a couple of references to SMP_MAXCPU which need to be
> changed to MAXCPU. I missed those. Oops.
>
> --
> John Birrell
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Alexandre "Sunny" Kovalenko (Олександр Коваленко)
Andrew Pogrebennyk
> On Sat, Feb 02, 2008 at 03:28:43PM +0200, Andrew Pogrebennyk wrote:
>> pointer to u_char like:
>> frame->tf_eip += dtrace_instr_size((u_char *) frame->tf_eip);
>> What do i do to get it to work?
>
>
> #include <machine/frame.h>
Thanks. Attached patch summarizes what I've done so far on i386 for
compilation to succeed. But one thing remains unresolved:
cc1: warnings being treated as errors
In file included from
/usr/src/sys/modules/dtrace/dtrace/../../../contrib/opensolaris/uts/common/dtrace/dtrace.c:121:
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/dtrace_debug.c:
In function 'dtrace_debug_lock':
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/dtrace_debug.c:73:
warning: implicit declaration of function 'dtrace_cmpset_long'
/usr/src/sys/modules/dtrace/dtrace/../../../cddl/dev/dtrace/dtrace_debug.c:73:
warning: nested extern declaration of 'dtrace_cmpset_long'
*** Error code 1
I see that in dtrace_debug.c definition of dtrace_cmpset_long() is
enclosed in #if defined(__amd64__) and there is no such definition for
i386. If I make gcc ignore errors, the kernel does not boot: it
complains on unresolved symbol 'dtrace_cmpset_long'.
--
Sincerely,
Andrew Pogrebennyk
Tom Judge
> On Sat, Feb 02, 2008 at 11:07:28PM +0000, Thomas Hurst wrote:
>
> maintains client state on the server. That's one of the
> disadvantages of perforce.
Tom Evans (CC'd), I believe has a ruby script that will grab stuff from
perforce automatically for you.
Tom
>
>> I remember looking a while ago and not finding anything. I also
>> remember a cvsup server linked to it at some point..
>
> There was, but some hardware problems got in the way of the
> export and the files weren't kept up-to-date. Since I am so
> close to committing to current, it isn't worth wasting the
> project admins' time getting it back up an running when it
> will be obsolete soon.
>
> I decide that I could distribute one big tar and then diffs from
> that, so although the initial download is huge, keeping the
> source tree up-to-date should be just a matter of applying a
> patch or two (or twenty).
>
Rui Paulo
On Feb 3, 2008, at 6:48 PM, Tom Judge wrote:
> John Birrell wrote:
>> On Sat, Feb 02, 2008 at 11:07:28PM +0000, Thomas Hurst wrote:
>>> Are there no anonymous checkouts from perforce?
>> Anonymous access to perforce isn't possible because perforce
>> maintains client state on the server. That's one of the
>> disadvantages of perforce.
>
> Tom Evans (CC'd), I believe has a ruby script that will grab stuff
> from perforce automatically for you.
>
IIRC, in the previous DTrace implementation for FreeBSD, the p4 branch
was publically accessible by cvsup via cvsup10.freebsd.org. Maybe
this could be done again.
Regards.
--
Rui Paulo
Tom Evans
> John Birrell wrote:
> > On Sat, Feb 02, 2008 at 11:07:28PM +0000, Thomas Hurst wrote:
> >> Are there no anonymous checkouts from perforce?
> >
> > Anonymous access to perforce isn't possible because perforce
> > maintains client state on the server. That's one of the
> > disadvantages of perforce.
>
> Tom Evans (CC'd), I believe has a ruby script that will grab stuff from
> perforce automatically for you.
>
>
> Tom
>
Ben Close kindly hosted the script for me on his wiki (the script was
designed to pull wpi snapshots). You can get it here:
http://www.clearchain.com/wiki/Image:P4fetch.rb
Cheers
Tom
Andrew Gallatin
With this installed, I'm seeing a problem running any
dtrace scripts:
dtrace: failed to compile script /nfs/home/gallatin/dtrace/printa.d:
"/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t"
I'm guessing dtrace doesn't know what a uid_t is. Is this some sort
of installation problem on my part?
While I was trying to figure out what was going on, the
machine fell over:
panic: solaris assert: ((__curthread())->td_proc) == p, file:
/var/tmp/dtrace/src/sys/modules/dtrace/fasttrap/../../../cddl/dev/fasttrap/fasttrap.c,line: 425
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x17d
fasttrap_fork() at fasttrap_fork+0x107
fork1() at fork1+0xdfc
kproc_create() at kproc_create+0x66
nfs_nfsiodnew() at nfs_nfsiodnew+0xc9
nfs_asyncio() at nfs_asyncio+0xb1
nfs_strategy() at nfs_strategy+0x54
bufstrategy() at bufstrategy+0x2c
nfs_writebp() at nfs_writebp+0xba
nfs_flush() at nfs_flush+0x80c
nfs_close() at nfs_close+0x1bf
vn_close() at vn_close+0x7d
vn_closefile() at vn_closefile+0x69
_fdrop() at _fdrop+0x23
closef() at closef+0x2a2
kern_close() at kern_close+0x15d
syscall() at syscall+0x274
Xfast_syscall() at Xfast_syscall+0xab
--- syscall (6, FreeBSD ELF64, close), rip = 0x800879d1c, rsp = 0x7fffffffe598, rbp = 0 ---
Uptime: 19m45s
Drew
John Birrell
>
> With this installed, I'm seeing a problem running any
> dtrace scripts:
>
> dtrace: failed to compile script /nfs/home/gallatin/dtrace/printa.d:
> "/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t"
>
> I'm guessing dtrace doesn't know what a uid_t is. Is this some sort
> of installation problem on my part?
Hmmm. That looks like a CTF conversion problem, assuming that uid_t
is actually referenced in our kernel (which I think it should be).
Does a ctfdump of the kernel list uid_t?
>
>
> While I was trying to figure out what was going on, the
> machine fell over:
>
> panic: solaris assert: ((__curthread())->td_proc) == p, file:
Ah that's WIP. I shouldn't have added fasttrap to the dtraceall
module dependencies. Can you take it out or just load all the other
modules manually? You wo't get anywhere trying to trace userland stuff
yet.
Andrew Gallatin
John Birrell writes:
> On Mon, Feb 04, 2008 at 04:34:12PM -0500, Andrew Gallatin wrote:
> >
> > With this installed, I'm seeing a problem running any
> > dtrace scripts:
> >
> > dtrace: failed to compile script /nfs/home/gallatin/dtrace/printa.d:
> > "/usr/lib/dtrace/psinfo.d", line 37: syntax error near "uid_t"
> >
> > I'm guessing dtrace doesn't know what a uid_t is. Is this some sort
> > of installation problem on my part?
>
> Hmmm. That looks like a CTF conversion problem, assuming that uid_t
> is actually referenced in our kernel (which I think it should be).
>
> Does a ctfdump of the kernel list uid_t?
There was no ctf data at all. I build kernels the old
fashioned way in /sys (no buildkernel), and I ran config
prior to installworld, so the makefile did not have the CTF
Total pilot error on my part, sorry to have bothered you!
> > panic: solaris assert: ((__curthread())->td_proc) == p, file:
>
> Ah that's WIP. I shouldn't have added fasttrap to the dtraceall
> module dependencies. Can you take it out or just load all the other
> modules manually? You wo't get anywhere trying to trace userland stuff
> yet.
That works, thanks!
FWIW, I was mainly looking to try some of the kernel
profiling scripts that I use on Solaris and MacOSX.
They're variations on the example scripts.
When I ran the following on a fairly busy system:
#!/usr/sbin/dtrace -s
profile:::profile-997
{
@a[stack(20)]=count();
}
END
{
trunc(@a, 20);
printa(@a);
}
I see nothing:
% ~/dtrace/profile_stack.d
dtrace: script '/nfs/home/gallatin/dtrace/profile_stack.d' matched 2
probes
<20 seconds elapses>
^C
CPU ID FUNCTION:NAME
2 2 :END
20064
Under similar load on Solaris (or MacOSX), I'd see a bunch of
different "hot" stacks. A few more tries hung the system for ~30
seconds, until it crashed:
bge0: watchdog timeout -- resetting
spin lock 0xffffffff80a5ac20 (smp rendezvous) held by 0xffffff008c96aa50 (tid 100135) too long
panic: spin lock held too long
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
panic() at panic+0x17d
_mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39
_mtx_lock_spin() at _mtx_lock_spin+0x9e
smp_rendezvous_cpus() at smp_rendezvous_cpus+0xe1
dtrace_xcall() at dtrace_xcall+0x6a
dtrace_state_deadman() at dtrace_state_deadman+0x19
cyclic_clock() at cyclic_clock+0x12b
lapic_handle_timer() at lapic_handle_timer+0x8b
Xtimerint() at Xtimerint+0x67
--- interrupt, rip = 0xffffffff806fd9e6, rsp = 0xffffffffac289b90, rbp = 0xffffffffac289ba0 ---
acpi_cpu_c1() at acpi_cpu_c1+0x6
acpi_cpu_idle() at acpi_cpu_idle+0x19c
sched_idletd() at sched_idletd+0x46
fork_exit() at fork_exit+0x11f
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xffffffffac289d30, rbp = 0 ---
FWIW, this is an 8-way opteron.
Drew
John Birrell
> @a[stack(20)]=count();
stack() is one of the things I haven't ported yet. :-)
Andrew Gallatin
John Birrell writes:
> On Tue, Feb 05, 2008 at 10:31:39AM -0500, Andrew Gallatin wrote:
> > @a[stack(20)]=count();
>
> stack() is one of the things I haven't ported yet. :-)
>
Ah, that would make sense then!
Drew
Greg Olin
environment and I tried a few changes with John's hint, but I haven't
found the solution. Can someone say specifically what they did to get
around this problem?
Thanks,
Greg