similar to: FBT Provider

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

I was wonderring if there is any quick way to check how many virtual registers are live-in at any give instruction of a function? Right now my understanding is that I would have to calculate the gen, kill, in and out sets and iterate over the entire functions CFG until the sets stop changing. Thanks _________________________________________________________________ Express your personality

Hello, a local prison contacted us regarding some calling card solution. they need 4 E1s to serve 120 rooms in that prison. we are planning on using 4 servers to serve the calls and one for the database servers' specifications are: 2.8 Dual Core Proccessors 2 GB Ram 160 Sata Drive each server will be provided with 1 E1 card Questions are: 1- will those servers be able to handle that ammount

Saw this mentioned on Lambda, and thought it was worth pointing out (though I'm betting most of you are Lambda readers). Looks like it's a new approach to mapping out optimizations and picking the best ordering/grouping. http://www.cse.ucsd.edu/~rtate/publications/eqsat/ Just watched the video and am settling down to read the paper, and it looks interesting so far. Anyone more

Hi All: In Solaris Dtrace User Guide, page 218, it says, "Functions that do not create a stack frame on x86 systems cannot be instrumented by FBT." Then what are these functions? What characteristics do they have? Regards TJ

what is differenct between syscall::write:entry fbt::write:entry are the two probe fires at the same place. -- This message posted from opensolaris.org

Tried to start up tcptop_snv on snv87 x86 and got <i>dtrace: failed to compile script /dev/fd/11: line 168: conn_tcp is not a member of struct conn_s</i> Line 288 has this line: <i>this->tcpp = (tcp_t *)this->connp->conn_tcp;</i> which, after looking at line 168 of <a

Whilst trying out some D to get an insight into what is the most common reason for a given function to return, I have bumped into an error I don''t understand. The first take on what I was trying to do was: # dtrace -n ''fbt:ip:ip_input:return{@home[arg0] = count();}'' and all was well. The next step was: # dtrace -n

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.

Is there any work on keeping DTraceTools up to date with the latest snv builds. These scripts are pretty useful and help get a novice dtrace user like me doing useful work quickly. Specifically the tcp stack tools like tcptop and tcpsnoop don''t work with later OpenSolaris builds. Thanks, Gary -- This message posted from opensolaris.org

All, The attached script is causing the following error message ... bash-3.00# ./zmon_bug.d dtrace: error on enabled probe ID 2 (ID 4394: fbt:genunix:copen:entry): invalid address (0xfd91747f) in predicate at DIF offset 120 dtrace: error on enabled probe ID 2 (ID 4394: fbt:genunix:copen:entry): invalid address (0xfef81a3f) in predicate at DIF offset 120 Any ideas? thxs Joe --

Is there a trick to listing available providers? I can''t find it.

FYI, I posted a blog a few days ago about a DTrace provider for NFS that is currently in development: http://blogs.sun.com/roller/page/samf?entry=a_dtrace_provider_for_nfs Let''s discuss any questions, comments, etc. here. I also advertised this on nfs-discuss at opensolaris.org. Naturally, I would expect the discussion here to be more on the specifics of DTrace, and the

Hi i''m trying to write my first dtrace script apparently i bit off a bit more than i can chew, i want to track io over sockets, i found your socketsize.d that gave me how to track writes, but i''m at a loss how to track reads, frankly i don''t see how your write tracker works because it uses a probe in a function that only takes two arguments but you grab size of write

Hi, I was going through the implementation of the fasttrap provider. I found that when displaced execution happens (ie., when the instruction traced is being executed out of the scratch space) if an asynchrnous signal comes we need to defer the delivery. Can somebody explain why this is necessary and how is it implemented? Thanks in advance Saravanan S -------------- next part -------------- An

OK, I''ve been fritzing around with something I noticed last night, thinking that I understood what was going on, but now it''s getting confusing again. A system that has been running for a couple of months had a hole in the probe ID list near the end in the middle of the fbt probes. And then a couple of syscall probes were stuck in the hole. It looked like this: ... 40311

If I use a simple dtrace script such as this: fbt::somefunc:entry{self->trace=1;} fbt::somefunc:return{self->trace=0;} fbt:::entry{} fbt:::return{printf("%lx", arg1);} then it will descend to whatever depth is necessary If I want to limit it to say 3 functions deep, how can I do that? The quick answer I want to use is to do "self->depth++" on each entry and then

Hiya, I''m trying to track down some throughput latency that our customer seems to be attributing to our product, I can''t see what he''s talking about, but I want to try and get some deeper granularity than I might get with something like smokeping, and maybe even see if its down to something tunable on our end. I''ve been looking for some examples on how

Hi. I would like to print out a field of a vnode, but the argument to the function is of type vnode_t **. If I set "this->vpp" to arg2 in an entry function to zfs_lookup(), I''d like to retrieve the value of one of the fields of *(this->vpp) in the return function. Something like the below (but the syntax below is not right): printf("zfs_lookup:

I''m curious to know what files are being used from a NFS server perspective. I''m unable to trace the client because it is in the boot phase. Looking at the io provider, I believe it does not allow you to look at what files are being requested. That would lead me to the fbt provider. Does anyone know what fbt provides the file handle for NFS client request on the NFS