search for: fasttrap

...DTrace Clients system SUNWdtrp DTrace Providers The minimized versions are the core with some added packages as needed but these server do not create the devices found under /devices/pseudo/ as you can see via a truss on a dtrace. open("/devices/pseudo/fasttrap at 0:fasttrap", O_RDONLY) Err#2 ENOENT open("/devices/pseudo/fbt at 0:fbt", O_RDONLY) Err#2 ENOENT open("/devices/pseudo/lockstat at 0:lockstat", O_RDONLY) Err#2 ENOENT open("/devices/pseudo/profile at 0:profile", O_RDONLY) Err#2 ENOENT open("/devices/pse...

Hey, Do you guys think that is a good idea to have a manual page for each provider with a complete description of what probes are offered ? Found some already under 7D category: dtrace dtrace (7d) - DTrace dynamic tracing facility fasttrap fasttrap (7d) - DTrace user instruction tracing provider fbt fbt (7d) - DTrace function boundary tracing provider lockstat lockstat (7d) - DTrace kernel lock instrumentation provider profile profile (7d) - DTrace profile interrupt provider sdt...

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

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 -...

...) automatically, run * "dtrace -A" without additional arguments. See the "Anonymous Tracing" * chapter of the Solaris Dynamic Tracing Guide for details. * forceload: drv/systrace forceload: drv/sdt forceload: drv/profile forceload: drv/lockstat forceload: drv/fbt forceload: drv/fasttrap forceload: drv/systrace forceload: drv/sdt forceload: drv/profile forceload: drv/lockstat forceload: drv/fbt forceload: drv/fasttrap forceload: drv/dtrace * ^^^^ Added by DTrace It''s because when libdtrace searches for providers, it searches the system module load paths and attempts...

...is defined and the address of the function in the _relocatable_ object. So, whenever I''m building a program with an usdt probe I get: libdtrace DEBUG: defined probe database:::query-start main() +0x13 (main) When I run ''dtrace -n ''database*:::'''' the fasttrap module inserts the probe at the 0x13 offset, not the actually vaddr of main() + offset. I added a debug printf in fasttrap_tracepoint_enable(): installing tracepoint on pid 1288 pc 0x13 Of course this doesn''t work because main() is actually at 0x4011d0. To overcome this I thought that d...

...08.63, syscall=1.80, csw=78.14 > per second: smtx=0.33, srw=0.00 > per second: migr=0.00 > * //Events are some syscalls or some user-defined functions. > > In a word, this program looks very like the mpstat. > > One of my testcases is running this program with dtrace''s fasttrap > provider, such as: > dtrace -n ''pid$targer::callee:entry{ ... }'' -c my_program > dtrace -n ''test$target:::callee{ ... }'' -c my_program > > The output is very strange. > *30.00 secs, 213099.33 per secs > user=99.6749%, kernel=0.3251%, idle=0...

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

...#error "Need to figure this out" #endif printf("ulwp_t is 0x%lx\n", addr); -------------------------------------------------------------------------------- But things don''t seem to be as simple as that for the 32-bit/32-bit case. From usr/src/uts/intel/dtrace/fasttrap_isa.c, we have this code for the i386 case (to get the address of the thread-local scratch space used for fasttrap probes, which is just after the ul_self pointer): -------------------------------------------------------------------------------- /* * Compute the ad...

On 12/24/06, James McIlree <jmcilree at apple.com> wrote: > > I''ve been reading still more code :-). > > I notice in fasttrap_disable_callbacks(), there is this snippet of > code: > > for (cur = cpu->cpu_next_onln; cur != cpu; > cur = cur->cpu_next_onln) { > rw_enter(&cur->cpu_ft_lock, RW_WRITER); > } > &g...

Is there a limit on the number of user space probes that can be present at any time? I have compiled very many probes into our product, and can''t see all of them in "dtrace -l". it looks very much like I have all of them up to some point at which I''ve hit some hard limit. I can see a total of 8588 probes, I think 2 processes have all of the ones I expect (one has 1752

Hi all, So I just took Sun''s dtrace class this week and one thing that piqued my interest was the instrumenting of a process''s instructions and how to find the original instructions. (I''m looking around at resources for learning SPARC assembly to help me when using mdb for analysis, though I vaguely remember pieces from a grad school compiler theory class about 10 years

I have just recently (physically) moved a system with 16 hard drives (for the array) and 1 OS drive; and in doing so, I needed to pull out the 16 drives so that it would be light enough for me to lift. When I plugged the drives back in, initially, it went into a panic-reboot loop. After doing some digging, I deleted the file /etc/zfs/zpool.cache. When I try to import the pool using the zpool

Hi, I just had my Dell R610 reboot with a kernel panic when I threw a couple of zfs clone commands in the terminal at it. Now, after the system had rebooted zfs will not import my pool anylonger and instead the kernel will panic again. I have had the same symptom on my other host, for which this one is basically the backup, so this one is my last line if defense. I tried to run zdb -e