similar to: dtrace causes powered down things to be powered up?

We are using following dtrace script to analyze an application. However we see different number of lwp_yield and yield calls reported depending on whether we trace mutex_lock or mutex_unlock or not. The number reported when we are not tracing mutex_lock or mutex_unlock is higher. What could be going on here and which one is the correct number. This is on S10 U2. Thanks, Rao.

Hello, According to http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=4970596 and other notes I read it appears that the ability to run dtrace programs (by having dtrace_proc and dtrace_user privileges configured inside NGZ''s) has been made available (through various projects) since build 37 of Nevada. I am not merely referring to configurable privileges alone, but to

Hi Nils, all, I tried the ''FBT-trick'' suggested below by Nils and (of course :-) ) it works and gives me a pile of output. Good enough to show that indeed Linux application behavior is not totally opaque, good enough to for instance show that ''system call mapping'' is taking place. I wonder, is there any documentation available for lxsyscall module ? To learn

Hi All, Can someone help me in getting info about specific dtrace features introduced in individual S10 updates like U1,U2,U3 etc... This message posted from opensolaris.org

Hi all, We just got a shiny new T5440, and one of the first things I noticed (besides the insane number of hardware contexts), is that dtrace takes 30 seconds to a minute to fire up scripts with 5-6 probes, where our T5220 usually takes under a second. Shutdown is similar, though slightly faster. This is mostly annoying because it takes so long to attach that it''s hard to tell when

Using the following dtrace command, I can see who''s calling what with lots of +/- numbers: dtrace -n ''fbt:ip:ip_output:entry{@dbtypes[((mblk_t *)arg1)->b_datap->db_type,caller] = count();}'' ...the output is what I want but not how I want to see it. What I''d rather see is the function names associated with caller and for db_type to be output in hex.

Hi all, I have questions about something I observed just now: 1) on AMD64, S10u1: # dtrace -n ''fbt::copystr:entry{printf ("%p\n", args[0]);}'' -c /bin/pwd dtrace: invalid probe specifier fbt::copystr:entry{printf ("%p\n", args[0]);}: in action list: index 0 is out of range for fbt::copystr:entry args[ ] but # dtrace -n ''fbt::copystr:entry{printf

Hi, Has something related to speculative tracing changed between s10 FCS and the more recent nevada builds ? I was trying the specopen.d script from the Dtrace guide on a nevada machine and it failed with : dtrace: failed to enable ''./spec.d'': DIF program content is invalid To try and narrow things down a bit I wrote the following short script. This works fine on s10, but

Francois Dion wrote: > Le lundi 16 avril 2007 ? 13:28 -0600, Ali Bahrami a ??crit : >>> Subject: >>> Re: [dtrace-discuss] Getting the function names? >>> From: >>> Bart Smaalders <bart.smaalders at Sun.COM> >>> Date: >>> Fri, 13 Apr 2007 09:48:29 -0700 >>> To: >>> fdion at atriumwindows.com >>> >>>

To remember all dtrace actions, aggregations and variables is a headache, even worse, they are not include in dtrace(1M) now. So here is a chance to have a CLI RFE - to have something like "dtrace --actions", which will list all actions, like this page: http://developers.sun.com/solaris/articles/dtrace_quickref/dtrace_functions.html "dtrace --aggregations", lists all

For those who may have missed the news, the DTrace movers and shakers have moved over to a new mailing list; you can sign up at http://dtrace.org/blogs/mailing-list/ And there will be a conference dedicated to DTrace on April 3rd in San Francisco, more information here: http://wiki.smartos.org/display/DOC/dtrace.conf -- best regards, Deirdr? Straughan SmartOS Community Manager Joyent cell

> > From: vikram b > > Date: October 22, 2009 12:31:53 AM PDT > > To: dtrace-discuss at opensolaris.org > > Subject: [dtrace-discuss] dtrace problem > > > > Hi All, > > I am running dtrace on linux !! got it working some how. > > dtrace -l shows a big list.. but many issues > > > > 1. says : failed to grab process > >

(Apologies to anyone who follows me on Twitter and therefore will have seen this multiple times already.) Joyent will be offering training in DTrace: Core Features and Performance Analysis trainer: Brendan Gregg <http://dtrace.org/blogs/brendan/> (San Francisco, Sept 6-7), Max Bruning <http://wiki.smartos.org/display/DOC/Max+Bruning> (Geneva, Sept 13-14) This course introduces

X.Org has adopted GNU autoconf as its build configuration mechanism, so when I integrated the dtrace probes, I checked to see if they should be built using this test, checking for the existence of a program named "dtrace" in the path: dnl Check for dtrace program (needed to build Xserver dtrace probes) AC_ARG_WITH(dtrace, AS_HELP_STRING([--with-dtrace=PATH], [Enable dtrace

Dear dtrace Experts, I have seen some dtrace utilities like opensnoop and execsnoop etc. My interest is to write a simple script that can snoop the files which uses the 3 syscalls like open,create,unlink. I have gone through dtrace oneliners that can do the same : dtrace -n ''syscall::open*:entry { printf("%s %s",execname,copyinstr(arg0));}'' dtrace -n

Have you considered the mdb dcmd ::pfiles? mfe at inker:~/Code/dtrace/examples$ *pfexec mdb -k* Loading modules: [ unix genunix specfs dtrace mac cpu.generic uppc pcplusmp scsi_vhci zfs ip hook neti sockfs arp usba uhci fctl s1394 stmf stmf_sbd md lofs random idm sd crypto fcp cpc fcip smbsrv nfs ufs logindmux ptm nsmb sppp nsctl sdbc rdc sv ii ipc ] > *::ps ! grep clock-applet* R 1744

The earlier post with the Dtrace probes definition (sent on April 23) was only to solicit feedback from all prospective users of iSCSI DTrace probes. I will follow up shortly with an updated document requesting approval from the community. thanks Priya -------- Original Message -------- Subject: Dtrace provider for the COMSTAR iscsi Target Port Provider - Review Request Date: Thu, 23 Apr

Hi, If you have a custom kernel (and therefore have duplicates of everything in /kernel in your custom kernel) and have noticed that when you try to use anonymous tracing, dtrace adds multiple copies of the forceload directives to /etc/system, e.g.: * vvvv Added by DTrace * * The following forceload directives were added by dtrace(1M) to allow for * tracing during boot. If these

The open solaris dtrace page (http://www.opensolaris.org/os/community/dtrace/) has a bad link to the DTrace Guide(http://docs.sun.com/db/doc/817-6223). This message posted from opensolaris.org

Hello, I''m trying to debug an issue with rpc.metad on Solaris 10, basecally I believe the failure path is - svc_init -- check_sys --- check_host ---- strcmp(hostname, mynode()) It seems that for some reason hostname and mynode didn''t match then I would like to use dtrace to show the argument of the strcmp However the dtrace pid provider can''t trace functions