gt;
>
> Ir. A. Adema BSc
> e-mail: aron.ad...@gmail.com or
> a...@famadema.com
> GSM:+31 6 55687405
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://mail.opensolaris.org/pipermail/dtrace-discuss/attachm
Customer Services
> >>
> >> Log, update, and monitor your Service Request online using My Oracle
> >> Support <http://www.oracle.com/us/support/044752.html>
> >>
> >>
> >> ___
> >> dtrace-discuss mailing list
> >> dtrace-discuss@opensolaris.org <mailto:dtrace-discuss@opensolaris.org>
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110711/30ac0744/attachment.html
> >
> -- next part --
> A non-text attachment was scrubbed...
> Name: oracle.jpg
> Type: image/jpeg
> Size: 8717 bytes
> Desc: not available
> URL: <
> http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110711/30ac0744/attachment.jpg
> >
> -- next part --
> An embedded and charset-unspecified text was scrubbed...
> Name: CSET.d
> URL: <
> http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110711/30ac0744/attachment.ksh
> >
>
> --
>
> ___
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
>
> End of dtrace-discuss Digest, Vol 75, Issue 8
> *
>
--
Michael Ernest
Inkling Research, Inc.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
.
> Name: not available
> Type: image/gif
> Size: 5953 bytes
> Desc: not available
> URL: <
> http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110105/0c91ef92/attachment.gif
> >
> -- next part --
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/x-pkcs7-signature
> Size: 5043 bytes
> Desc: not available
> URL: <
> http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20110105/0c91ef92/attachment.bin
> >
>
> --
>
> ___
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
>
> End of dtrace-discuss Digest, Vol 69, Issue 2
> *
>
--
Michael Ernest
Inkling Research, Inc.
--
Michael Ernest
Inkling Research, Inc.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
nsolaris.org/pipermail/dtrace-discuss/attachments/20110105/0c91ef92/attachment.html
> >
> -- next part --
> A non-text attachment was scrubbed...
> Name: not available
> Type: image/gif
> Size: 5953 bytes
> Desc: not available
> URL: <
> htt
It turns out I have partially addressed bug #6537769:
http://bugs.opensolaris.org/view_bug.do?bug_id=6537769
The current state of the bug report is 6-Fix Understood and has not been
updated since July '08.
One question I had was how a CPU caps example was best documented; either in
the body o
After a deeper review of the tables in this section of wiki, I noticed the
following more persnickety elements:
The descriptions for the probes exec-failure and exec-success state that they
fire "only after the exec probe has fired in the same thread." I am not aware
of a case where one probe f
ones, and remove the duplicate noted in 6207856. Bugster says a fix
is in place for 6207856 but I gather it's fallen through the cracks.
Michael
--
Michael Ernest
Inkling Research, Inc.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
;s ok.
My apologies for not following protocol.
Regards,
Michael
--
Michael Ernest
Inkling Research, Inc.
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
The code that's barking is here:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/common/dt_decl.c#926
The files in /usr/lib/dtrace read in environment values and translators for use
by any DTrace program. As a workaround, you could probably rename this file or
move i
Thought I'd paste this in from the emails just for completeness' sake:
The vmstat code does the following:
a) get system pagesize
b) bit-shift right by ten (thus 8192 reduces to 8, 4096 reduces to 4)
c) defines a macro to multiply the bit-shifted value with the pgin count
which renders a result
Since DTrace buffers the information on a per-CPU basis, there's a chance on a
multi-sumpn system that the buffers may be consumed out of turn. Your exiting
stuff is recorded later, but every once in a while the buffer it was written to
is consumed first, and so it looks like the events themselv
Is this by any chance running on a multi-core system?
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
A system() invocation is governed by buffer switchrate. The system() action
executes only when the containing buffer gets read. With default buffer policy
and switchrate, almost a second could go by before that happens.
So any process thread that fires the probe but terminates before the system(
I would first try prtconf -v to see if the bus speed is listed as a property of
the bus' driver.
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
Thanks for spelling that out what you were working with.
As a matter of style, splitting the test logic across probe declarations sure
would be easier to read (and reread).
All that opt_* test logic in one predicate requires the maintainer to
understand the preamble. For example, when is OPT_c
It hangs Solaris in a way that I would guess is hard swapping. Then I left the
predicate for the fbt probe off by accident, and it ran like a champ. Now I
don't think it's caused by enabling too many probes. Add the predicate to the
fbt, though, and it freezes.
I didn't mention my -F for brevit
I've been playing with a follow script example and getting a system hang every
time. Turns out when I try:
syscall::read:entry /execname == "ls" / { self->tr = 1; }
fbt::: {}
syscall::read:return /self->tr / { self->tr = 0; }
I get (unusable) output. But when I add /self->tr / to my fbt::: clau
Thanks Adam.
I thought there was a common theme that naturally brought the "lifecycle"
probes and the flow control discussion together. Doesn't really work. I think
some comment on program lifecycle in the scripting chapter is appropriate, but
I don't know if it add much to what's already in th
Here's a stab at including something on flow control in the wiki. I feel like
it needs a killer example. Something less contrived than the profile loop and
less complicated than what's in speculative tracing. Any ideas?
Suggestions, improvements?
***
Flow Control in D Programs
The dtrace provi
I agree, and posted an ECB-less version.
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
***
Incidentally, the I/O provider chapter doesn't ever explain why most of the
examples use associative arrays instead of self. Worse, the second to last
example actually does use self to communicate between io:::start and io:::end
(that's a bug, right?).
***
Did you mean io:::done? If so, I'm
Using Chad's description above as a base, I propose the following addition to
http://wikis.sun.com/display/DTrace/D+Program+Structure. I think it would work
well directly below the Actions section:
***
Order of Execution
Once submitted, each clause is represented by an enabling control block (
At this point, I'm guessing I recreated all your experiments with all the same
results. I vaguely knew I was going down a wrong path, but any amount of RTFM
(more like GTFI) wasn't helping. It finally dawned on me that DTrace doesn't
actually know what's in a userland struct.
I came across a bl
Uh huh, and what about trace(copyinstr(self->spwd->sp_namp)) ?
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
The automagic here is performed by trace() and DTrace's string type. trace()
operates the same way on D strings as it does with C char *'s. Try trace(*s)
and note the difference. Dereferencing within trace() returns only the
character at the given address.
When you say trace(s) gives the correc
Did everyone else see this portion of Jonathan's latest response (the very end)?
6492 1
> 6494 1
> 6495 1
> 6496 1
> 6497 1
> 6498 1
> ...
>
>
> Note that this gives you more data than you were asking for; you also know
> how many items are being processed at any given time.
>
> Most problems you
I had something crudely similar to feed to bc, using "" for a key and omitting
it from the printa() output, a la:
printa("@d...@d\n", @e, @r);
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
That was a weird typo. Appreciate the catch.
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
One aspect of DTrace I enjoy is that you can show people something surprising
without a lot of foundational knowledge.
You can ask a question like this: If you wanted to know how many processes were
running on your system at any time, how would you do it? Most people even
lightly familiar with
Anyone interested in replicating? Here's the dtrace one-liner I used:
dtrace -n '::bdev_strategy:entry {}'
And here's the panic string from one attempt:
panic[cpu0]/thread=d3c2bde0:
BAD TRAP: type=e (#pf=Page Fault) rp=d3c2bc30 address=0 occurred in module
"" due to a NULL pointer dereference.
Sorry for the triple-clutch on that last post.
These crash files are monsters; the core image is 83M *after* gzipping, and I'm
only dumping kernel pages.
What's the limit on file upload to this site?
M
--
This message posted from opensolaris.org
_
Oops, I spoke too soon. I thought it was dumping core, owing to the significant
delay after locking. However I haven't yet persuaded this setup to recover the
dump files (dumpadm shows proper config). I'll provide one as soon as I get
that going.
--
This message posted from opensolaris.org
___
I'm running OpenSolaris 2008.05 in VirtualBox on a Windows XP host. Playing
around with various probes, I found that trying to load any probe associated
with bdev_strategy dumps core.
I can think of one or two likely and reasonable causes for this, but am
assuming it's undesirable behavior.
A
33 matches
Mail list logo
