We have been working for months with Sun on trying to get to the bottom of resolving a panic issue on Solaris 10 x86 that always shows hment_remove as being the place it occurs. Does anyone know of a way to use Dtrace to get to the bottom of this problem? We are surprised that Dtrace has not been used to solve this problem since this is one of the types of problems it is suppose help solve. Regards, Carlton This message posted from opensolaris.org
If you''re getting the message generated by this code:
if (hm == NULL) {
panic("hment_remove() missing in hash table pp=%lx,
ht=%lx,"
"entry=0x%x hash index=0x%x", (uintptr_t)pp,
(uintptr_t)ht,
entry, idx);
Then I''d set up a D program that traced fbt::hment_remove:entry, and
then record the value of the argv elements for this function, and as
many data items as these pointers will get you too, as is reasonable.
Leave the D program running until the system panics, and then use the
postmortem tracing technique described in the DTrace guide to get
contents of the trace buffer. (make sure you specify a ring buffer policy).
You''ll have to plan what you record carefully against the culprit
function:
http://cvs.opensolaris.org/source/xref/on/usr/src/uts/i86pc/vm/hment.c#495
to try and get the most out of the crash. (keeping mind that there might
be changes to the code in the OpenSolaris release, if you''re not use
the
latest build.)
I should probably add that I''ve never tried postmortem tracing. ;-)
Also, are you aware that there are several bug reports on sunsolve
regarding this panic?
Good luck!
Chip
Carlton Teel wrote:> We have been working for months with Sun on trying to get to the bottom of
resolving a panic issue on Solaris 10 x86 that always shows hment_remove as
being the place it occurs. Does anyone know of a way to use Dtrace to get to
the bottom of this problem? We are surprised that Dtrace has not been used to
solve this problem since this is one of the types of problems it is suppose help
solve.
>
> Regards,
> Carlton
>
>
> This message posted from opensolaris.org
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>
Carlton, I work in kernel frontline support, have you opened a Sun case and provided the core files? That is usually the best way to root cause a panic. I could see Dtrace perhaps being used if it were some new bug that we were unclear on how it can happen so we come up with some probe to fire at the right time to help debug the root cause, but I would think that would only be necessary if the core file analyis, and code review is not sufficient to solve it. Chip Bennett wrote On 09/28/06 20:47,:> If you''re getting the message generated by this code: > > if (hm == NULL) { > panic("hment_remove() missing in hash table pp=%lx, ht=%lx," > "entry=0x%x hash index=0x%x", (uintptr_t)pp, (uintptr_t)ht, > entry, idx); > > Then I''d set up a D program that traced fbt::hment_remove:entry, and > then record the value of the argv elements for this function, and as > many data items as these pointers will get you too, as is reasonable. > Leave the D program running until the system panics, and then use the > postmortem tracing technique described in the DTrace guide to get > contents of the trace buffer. (make sure you specify a ring buffer policy). > > You''ll have to plan what you record carefully against the culprit > function: > http://cvs.opensolaris.org/source/xref/on/usr/src/uts/i86pc/vm/hment.c#495 > to try and get the most out of the crash. (keeping mind that there might > be changes to the code in the OpenSolaris release, if you''re not use the > latest build.) > > I should probably add that I''ve never tried postmortem tracing. ;-) > > Also, are you aware that there are several bug reports on sunsolve > regarding this panic? > > Good luck! > > Chip > > > Carlton Teel wrote: > >>We have been working for months with Sun on trying to get to the bottom of resolving a panic issue on Solaris 10 x86 that always shows hment_remove as being the place it occurs. Does anyone know of a way to use Dtrace to get to the bottom of this problem? We are surprised that Dtrace has not been used to solve this problem since this is one of the types of problems it is suppose help solve. >> >>Regards, >>Carlton >> >> >>This message posted from opensolaris.org >>_______________________________________________ >>dtrace-discuss mailing list >>dtrace-discuss at opensolaris.org >> > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Katie DeMore Kernel Support Engineer Sun Microsystems, Inc. 1 Network Drive, BUR04-B726 Burlington, MA 01803 Phone: 781-442-0321 katherine.demore at sun.com Work Hours: Mon-Fri: 7:30 a.m. - 4:00 p.m. EST Submit, check and update tickets at http://www.sun.com/service/online ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sun Microsystems <> Sun Services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi OK, so it sounds like this has been escalated above kernel frontline to engineering. I was just checking. I suppose you can forward the info you got from Chip to the case owner who can then forward that to the person who owns the technical escalation for them to consider. Katie Carlton Teel wrote On 09/29/06 09:09,:> Katie, > > We have a couple of tickets open regarding this problem since it is occuring > on both Sun and HP platforms. Sun has analyzed many core files and has > provided a three IDR patches, but none have fixed the problem. We are > hoping for another IDR very soon in hopes of fixing this problem, but in the > meantime I was wondering if Dtrace could be used to help track down this > problem. > > Carlton > > Katie Demore wrote: > >>Carlton, >> >>I work in kernel frontline support, have you opened a Sun case and >>provided the core files? That is usually the best way to root cause a >>panic. I could see Dtrace perhaps being used if it were some new bug >>that we were unclear on how it can happen so we come up with some probe >>to fire at the right time to help debug the root cause, but I would >>think that would only be necessary if the core file analyis, and code >>review is not sufficient to solve it. >> >> >> >>Chip Bennett wrote On 09/28/06 20:47,: >> >> >>>If you''re getting the message generated by this code: >>> >>>if (hm == NULL) { >>> panic("hment_remove() missing in hash table pp=%lx, ht=%lx," >>> "entry=0x%x hash index=0x%x", (uintptr_t)pp, (uintptr_t)ht, >>> entry, idx); >>> >>>Then I''d set up a D program that traced fbt::hment_remove:entry, and >>>then record the value of the argv elements for this function, and as >>>many data items as these pointers will get you too, as is reasonable. >>>Leave the D program running until the system panics, and then use the >>>postmortem tracing technique described in the DTrace guide to get >>>contents of the trace buffer. (make sure you specify a ring buffer policy). >>> >>>You''ll have to plan what you record carefully against the culprit >>>function: >>>http://cvs.opensolaris.org/source/xref/on/usr/src/uts/i86pc/vm/hment.c#495 >>>to try and get the most out of the crash. (keeping mind that there might >>>be changes to the code in the OpenSolaris release, if you''re not use the >>>latest build.) >>> >>>I should probably add that I''ve never tried postmortem tracing. ;-) >>> >>>Also, are you aware that there are several bug reports on sunsolve >>>regarding this panic? >>> >>>Good luck! >>> >>>Chip >>> >>> >>>Carlton Teel wrote: >>> >>> >>> >>>>We have been working for months with Sun on trying to get to the bottom of resolving a panic issue on Solaris 10 x86 that always shows hment_remove as being the place it occurs. Does anyone know of a way to use Dtrace to get to the bottom of this problem? We are surprised that Dtrace has not been used to solve this problem since this is one of the types of problems it is suppose help solve. >>>> >>>>Regards, >>>>Carlton >>>> >>>> >>>>This message posted from opensolaris.org >>>>_______________________________________________ >>>>dtrace-discuss mailing list >>>>dtrace-discuss at opensolaris.org >>>> >>>> >>>> >>>_______________________________________________ >>>dtrace-discuss mailing list >>>dtrace-discuss at opensolaris.org >>> >>> >> >> >>-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Katie DeMore Kernel Support Engineer Sun Microsystems, Inc. 1 Network Drive, BUR04-B726 Burlington, MA 01803 Phone: 781-442-0321 katherine.demore at sun.com Work Hours: Mon-Fri: 7:30 a.m. - 4:00 p.m. EST Submit, check and update tickets at http://www.sun.com/service/online ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sun Microsystems <> Sun Services ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi,
I constructed a small D-program trying to capture system
call related fbt entry probes. I ran this program in
one terminal window and "ls" command in another then
killed this program with <Control C>. Sometimes I got
the output but most of times I did not get any output at
all. This means Dtrace can not reliably capture the
function boundaries specified in this D-program. Below
is the program and its output:
% cat syscall.d
#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN
{
exclude["sched"] = 1;
exclude["fmd"] = 1;
exclude["inetd"] = 1;
exclude["in.routed"] = 1;
exclude["sendmail"] = 1;
exclude["snmpd"] = 1;
exclude["utmpd"] = 1;
exclude["svc.startd"] = 1;
exclude["svc.configd"] = 1;
exclude["nscd"] = 1;
exclude["automountd"] = 1;
exclude["nfsmapid"] = 1;
exclude["sh"] = 1;
exclude["csh"] = 1;
exclude["ksh"] = 1;
}
fbt:genunix:brk:entry,
fbt:genunix:chdir:entry,
fbt:genunix:chmod:entry,
fbt:genunix:chown:entry,
fbt:genunix:chroot:entry,
fbt:genunix:cladm:entry,
fbt:genunix:clock_getres:entry,
fbt:genunix:clock_gettime:entry,
fbt:genunix:clock_settime:entry,
fbt:genunix:close:entry,
fbt:genunix:fcntl:entry,
fbt:genunix:fstat:entry,
fbt:genunix:fstatvfs:entry,
fbt:genunix:getcwd:entry,
fbt:genunix:getdents64:entry,
fbt:genunix:getpid:entry,
fbt:genunix:gtime:entry,
fbt:genunix:ioctl:entry,
fbt:genunix:lstat:entry,
fbt:genunix:memcntl:entry,
fbt:genunix:munmap:entry,
fbt:genunix:open:entry,
fbt:genunix:open64:entry,
fbt:genunix:resolvepath:entry,
fbt:genunix:rexit:entry,
fbt:genunix:stat:entry,
fbt:genunix:write:entry,
fbt:genunix:writev:entry
/!exclude[execname] && !progenyof($pid)/
{
@[execname, probefunc] = count();
}
% syscall.d
^C
ls fcntl 1
ls getpid 1
ls gtime 1
ls rexit 1
ls getdents64 2
ls ioctl 3
ls memcntl 3
ls brk 4
ls close 5
ls munmap 5
ls resolvepath 6
ls write 6
% syscall.d
^C
%
Let me know if there is anything wrong in my D-program.
Thanks.
************************************************
* C P Lin, Common Technology Project Lead. *
* Sun Microsystems Inc. *
* E-Mail: c.lin at sun.com *
* Address: 4150 Network Circle, M/S UMPK12-330 *
* Santa Clara, CA 95054 *
* Phone: 650/352-4967 Fax: 650/786-7816 *
************************************************
Hi,
I constructed a small D-program trying to capture system
call related fbt entry probes. I ran this program in
one terminal window and "ls" command in another then
killed this program with <Control C>. Sometimes I got
the output but most of times I did not get any output at
all. This means Dtrace can not reliably capture the
function boundaries specified in this D-program. Below
is the program and its output:
% cat syscall.d
#!/usr/sbin/dtrace -s
#pragma D option quiet
BEGIN
{
exclude["sched"] = 1;
exclude["fmd"] = 1;
exclude["inetd"] = 1;
exclude["in.routed"] = 1;
exclude["sendmail"] = 1;
exclude["snmpd"] = 1;
exclude["utmpd"] = 1;
exclude["svc.startd"] = 1;
exclude["svc.configd"] = 1;
exclude["nscd"] = 1;
exclude["automountd"] = 1;
exclude["nfsmapid"] = 1;
exclude["sh"] = 1;
exclude["csh"] = 1;
exclude["ksh"] = 1;
}
fbt:genunix:brk:entry,
fbt:genunix:chdir:entry,
fbt:genunix:chmod:entry,
fbt:genunix:chown:entry,
fbt:genunix:chroot:entry,
fbt:genunix:cladm:entry,
fbt:genunix:clock_getres:entry,
fbt:genunix:clock_gettime:entry,
fbt:genunix:clock_settime:entry,
fbt:genunix:close:entry,
fbt:genunix:fcntl:entry,
fbt:genunix:fstat:entry,
fbt:genunix:fstatvfs:entry,
fbt:genunix:getcwd:entry,
fbt:genunix:getdents64:entry,
fbt:genunix:getpid:entry,
fbt:genunix:gtime:entry,
fbt:genunix:ioctl:entry,
fbt:genunix:lstat:entry,
fbt:genunix:memcntl:entry,
fbt:genunix:munmap:entry,
fbt:genunix:open:entry,
fbt:genunix:open64:entry,
fbt:genunix:resolvepath:entry,
fbt:genunix:rexit:entry,
fbt:genunix:stat:entry,
fbt:genunix:write:entry,
fbt:genunix:writev:entry
/!exclude[execname] && !progenyof($pid)/
{
@[execname, probefunc] = count();
}
% syscall.d
^C
ls fcntl 1
ls getpid 1
ls gtime 1
ls rexit 1
ls getdents64 2
ls ioctl 3
ls memcntl 3
ls brk 4
ls close 5
ls munmap 5
ls resolvepath 6
ls write 6
% syscall.d
^C
%
Let me know if there is anything wrong in my D-program.
Thanks.
************************************************
* C P Lin, Common Technology Project Lead. *
* Sun Microsystems Inc. *
* E-Mail: c.lin at sun.com *
* Address: 4150 Network Circle, M/S UMPK12-330 *
* Santa Clara, CA 95054 *
* Phone: 650/352-4967 Fax: 650/786-7816 *
************************************************
I wonder if sometimes you''re entering the "ls" command before DTrace has completed compilation and instrumentation. If I take out the "#pragma D option quiet", it takes a little over 4 seconds for the "dtrace: script ''syscall.d'' matched 29 probes" message to appear. If you''re executing "ls" before DTrace is ready, no trace records will be recorded for that process. This is why the "-c" flag with $target is a good idea. It guarantees DTrace will be ready before the command starts. Chip CHIAN-PHON LIN wrote:> Hi, > > I constructed a small D-program trying to capture system > call related fbt entry probes. I ran this program in > one terminal window and "ls" command in another then > killed this program with <Control C>. Sometimes I got > the output but most of times I did not get any output at > all. This means Dtrace can not reliably capture the > function boundaries specified in this D-program. Below > is the program and its output: > > % cat syscall.d > #!/usr/sbin/dtrace -s > #pragma D option quiet > BEGIN > { > exclude["sched"] = 1; > exclude["fmd"] = 1; > exclude["inetd"] = 1; > exclude["in.routed"] = 1; > exclude["sendmail"] = 1; > exclude["snmpd"] = 1; > exclude["utmpd"] = 1; > exclude["svc.startd"] = 1; > exclude["svc.configd"] = 1; > exclude["nscd"] = 1; > exclude["automountd"] = 1; > exclude["nfsmapid"] = 1; > exclude["sh"] = 1; > exclude["csh"] = 1; > exclude["ksh"] = 1; > } > fbt:genunix:brk:entry, > fbt:genunix:chdir:entry, > fbt:genunix:chmod:entry, > fbt:genunix:chown:entry, > fbt:genunix:chroot:entry, > fbt:genunix:cladm:entry, > fbt:genunix:clock_getres:entry, > fbt:genunix:clock_gettime:entry, > fbt:genunix:clock_settime:entry, > fbt:genunix:close:entry, > fbt:genunix:fcntl:entry, > fbt:genunix:fstat:entry, > fbt:genunix:fstatvfs:entry, > fbt:genunix:getcwd:entry, > fbt:genunix:getdents64:entry, > fbt:genunix:getpid:entry, > fbt:genunix:gtime:entry, > fbt:genunix:ioctl:entry, > fbt:genunix:lstat:entry, > fbt:genunix:memcntl:entry, > fbt:genunix:munmap:entry, > fbt:genunix:open:entry, > fbt:genunix:open64:entry, > fbt:genunix:resolvepath:entry, > fbt:genunix:rexit:entry, > fbt:genunix:stat:entry, > fbt:genunix:write:entry, > fbt:genunix:writev:entry > /!exclude[execname] && !progenyof($pid)/ > { > @[execname, probefunc] = count(); > } > % syscall.d > ^C > > ls fcntl 1 > ls getpid 1 > ls gtime 1 > ls rexit 1 > ls getdents64 2 > ls ioctl 3 > ls memcntl 3 > ls brk 4 > ls close 5 > ls munmap 5 > ls resolvepath 6 > ls write 6 > > % syscall.d > ^C > > % > > > Let me know if there is anything wrong in my D-program. > > Thanks. > > > ************************************************ > * C P Lin, Common Technology Project Lead. * > * Sun Microsystems Inc. * > * E-Mail: c.lin at sun.com * > * Address: 4150 Network Circle, M/S UMPK12-330 * > * Santa Clara, CA 95054 * > * Phone: 650/352-4967 Fax: 650/786-7816 * > ************************************************ > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Chip, You are right. I took out "quiet" and waited for "matched" message before running "ls" and captured all output reliably. Thanks a lot for pointing out my operation error. I am developing a test coverage program called Qtrace. One of the Qtrace users want to be able to see the key kernel entries corresponding to his test program''s system calls during the first run of his test program. This is the motive that I am experimenting this D-program. The reason I am not using "-c" option is that it is not practical to instrument each C-program with "dtrace -c" in the user''s test script. The user''s application is always running with background Dtrace in Qtrace. Thanks. Chip Bennett wrote On 09/30/06 13:25,:> I wonder if sometimes you''re entering the "ls" command before DTrace has > completed compilation and instrumentation. If I take out the "#pragma D > option quiet", it takes a little over 4 seconds for the "dtrace: script > ''syscall.d'' matched 29 probes" message to appear. If you''re executing > "ls" before DTrace is ready, no trace records will be recorded for that > process. > > This is why the "-c" flag with $target is a good idea. It guarantees > DTrace will be ready before the command starts. > > Chip > > CHIAN-PHON LIN wrote: > >> Hi, >> >> I constructed a small D-program trying to capture system >> call related fbt entry probes. I ran this program in >> one terminal window and "ls" command in another then >> killed this program with <Control C>. Sometimes I got >> the output but most of times I did not get any output at >> all. This means Dtrace can not reliably capture the >> function boundaries specified in this D-program. Below >> is the program and its output: >> >> % cat syscall.d >> #!/usr/sbin/dtrace -s >> #pragma D option quiet >> BEGIN >> { >> exclude["sched"] = 1; >> exclude["fmd"] = 1; >> exclude["inetd"] = 1; >> exclude["in.routed"] = 1; >> exclude["sendmail"] = 1; >> exclude["snmpd"] = 1; >> exclude["utmpd"] = 1; >> exclude["svc.startd"] = 1; >> exclude["svc.configd"] = 1; >> exclude["nscd"] = 1; >> exclude["automountd"] = 1; >> exclude["nfsmapid"] = 1; >> exclude["sh"] = 1; >> exclude["csh"] = 1; >> exclude["ksh"] = 1; >> } >> fbt:genunix:brk:entry, >> fbt:genunix:chdir:entry, >> fbt:genunix:chmod:entry, >> fbt:genunix:chown:entry, >> fbt:genunix:chroot:entry, >> fbt:genunix:cladm:entry, >> fbt:genunix:clock_getres:entry, >> fbt:genunix:clock_gettime:entry, >> fbt:genunix:clock_settime:entry, >> fbt:genunix:close:entry, >> fbt:genunix:fcntl:entry, >> fbt:genunix:fstat:entry, >> fbt:genunix:fstatvfs:entry, >> fbt:genunix:getcwd:entry, >> fbt:genunix:getdents64:entry, >> fbt:genunix:getpid:entry, >> fbt:genunix:gtime:entry, >> fbt:genunix:ioctl:entry, >> fbt:genunix:lstat:entry, >> fbt:genunix:memcntl:entry, >> fbt:genunix:munmap:entry, >> fbt:genunix:open:entry, >> fbt:genunix:open64:entry, >> fbt:genunix:resolvepath:entry, >> fbt:genunix:rexit:entry, >> fbt:genunix:stat:entry, >> fbt:genunix:write:entry, >> fbt:genunix:writev:entry >> /!exclude[execname] && !progenyof($pid)/ >> { >> @[execname, probefunc] = count(); >> } >> % syscall.d >> ^C >> >> ls fcntl 1 >> ls getpid 1 >> ls gtime 1 >> ls rexit 1 >> ls getdents64 2 >> ls ioctl 3 >> ls memcntl 3 >> ls brk 4 >> ls close 5 >> ls munmap 5 >> ls resolvepath 6 >> ls write 6 >> >> % syscall.d >> ^C >> >> % >> >> >> Let me know if there is anything wrong in my D-program. >> >> Thanks. >> >> >> ************************************************ >> * C P Lin, Common Technology Project Lead. * >> * Sun Microsystems Inc. * >> * E-Mail: c.lin at sun.com * >> * Address: 4150 Network Circle, M/S UMPK12-330 * >> * Santa Clara, CA 95054 * >> * Phone: 650/352-4967 Fax: 650/786-7816 * >> ************************************************ >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- ************************************************ * C P Lin, Common Technology Project Lead. * * Sun Microsystems Inc. * * E-Mail: c.lin at sun.com * * Address: 4150 Network Circle, M/S UMPK12-330 * * Santa Clara, CA 95054 * * Phone: 650/352-4967 Fax: 650/786-7816 * ************************************************
I knew there had to be a good reason why you were tracking system calls using fbt instead of syscall and tracking a target by excluding everything that''s not the target. ;-) Chip CHIAN-PHON LIN wrote:> Chip, > > You are right. I took out "quiet" and waited for "matched" > message before running "ls" and captured all output reliably. > Thanks a lot for pointing out my operation error. > > I am developing a test coverage program called Qtrace. One of > the Qtrace users want to be able to see the key kernel entries > corresponding to his test program''s system calls during the > first run of his test program. This is the motive that I am > experimenting this D-program. The reason I am not using "-c" > option is that it is not practical to instrument each C-program > with "dtrace -c" in the user''s test script. The user''s > application is always running with background Dtrace in Qtrace. > > Thanks. > > Chip Bennett wrote On 09/30/06 13:25,: >> I wonder if sometimes you''re entering the "ls" command before DTrace >> has completed compilation and instrumentation. If I take out the >> "#pragma D option quiet", it takes a little over 4 seconds for the >> "dtrace: script ''syscall.d'' matched 29 probes" message to appear. If >> you''re executing "ls" before DTrace is ready, no trace records will >> be recorded for that process. >> >> This is why the "-c" flag with $target is a good idea. It guarantees >> DTrace will be ready before the command starts. >> >> Chip >> >> CHIAN-PHON LIN wrote: >> >>> Hi, >>> >>> I constructed a small D-program trying to capture system >>> call related fbt entry probes. I ran this program in >>> one terminal window and "ls" command in another then >>> killed this program with <Control C>. Sometimes I got >>> the output but most of times I did not get any output at >>> all. This means Dtrace can not reliably capture the >>> function boundaries specified in this D-program. Below >>> is the program and its output: >>> >>> % cat syscall.d >>> #!/usr/sbin/dtrace -s >>> #pragma D option quiet >>> BEGIN >>> { >>> exclude["sched"] = 1; >>> exclude["fmd"] = 1; >>> exclude["inetd"] = 1; >>> exclude["in.routed"] = 1; >>> exclude["sendmail"] = 1; >>> exclude["snmpd"] = 1; >>> exclude["utmpd"] = 1; >>> exclude["svc.startd"] = 1; >>> exclude["svc.configd"] = 1; >>> exclude["nscd"] = 1; >>> exclude["automountd"] = 1; >>> exclude["nfsmapid"] = 1; >>> exclude["sh"] = 1; >>> exclude["csh"] = 1; >>> exclude["ksh"] = 1; >>> } >>> fbt:genunix:brk:entry, >>> fbt:genunix:chdir:entry, >>> fbt:genunix:chmod:entry, >>> fbt:genunix:chown:entry, >>> fbt:genunix:chroot:entry, >>> fbt:genunix:cladm:entry, >>> fbt:genunix:clock_getres:entry, >>> fbt:genunix:clock_gettime:entry, >>> fbt:genunix:clock_settime:entry, >>> fbt:genunix:close:entry, >>> fbt:genunix:fcntl:entry, >>> fbt:genunix:fstat:entry, >>> fbt:genunix:fstatvfs:entry, >>> fbt:genunix:getcwd:entry, >>> fbt:genunix:getdents64:entry, >>> fbt:genunix:getpid:entry, >>> fbt:genunix:gtime:entry, >>> fbt:genunix:ioctl:entry, >>> fbt:genunix:lstat:entry, >>> fbt:genunix:memcntl:entry, >>> fbt:genunix:munmap:entry, >>> fbt:genunix:open:entry, >>> fbt:genunix:open64:entry, >>> fbt:genunix:resolvepath:entry, >>> fbt:genunix:rexit:entry, >>> fbt:genunix:stat:entry, >>> fbt:genunix:write:entry, >>> fbt:genunix:writev:entry >>> /!exclude[execname] && !progenyof($pid)/ >>> { >>> @[execname, probefunc] = count(); >>> } >>> % syscall.d >>> ^C >>> >>> ls fcntl 1 >>> ls getpid 1 >>> ls gtime 1 >>> ls rexit 1 >>> ls getdents64 2 >>> ls ioctl 3 >>> ls memcntl 3 >>> ls brk 4 >>> ls close 5 >>> ls munmap 5 >>> ls resolvepath 6 >>> ls write 6 >>> >>> % syscall.d >>> ^C >>> >>> % >>> >>> >>> Let me know if there is anything wrong in my D-program. >>> >>> Thanks. >>> >>> >>> ************************************************ >>> * C P Lin, Common Technology Project Lead. * >>> * Sun Microsystems Inc. * >>> * E-Mail: c.lin at sun.com * >>> * Address: 4150 Network Circle, M/S UMPK12-330 * >>> * Santa Clara, CA 95054 * >>> * Phone: 650/352-4967 Fax: 650/786-7816 * >>> ************************************************ >>> _______________________________________________ >>> dtrace-discuss mailing list >>> dtrace-discuss at opensolaris.org >> >> >> _______________________________________________ >> dtrace-discuss mailing list >> dtrace-discuss at opensolaris.org >