> Hi Przemol,
>
> [EMAIL PROTECTED] wrote:
> > I have encountered problem described in
> >
> http://www.opensolaris.org/jive/thread.jspa?messageID=
> 127449
> > (plockstat core dump).
> > - does anybody know which patch fixes it ?
> > - is the temporary solution mentioned at the above
> URL (echo
On 9/4/07, James Carlson <[EMAIL PROTECTED]> wrote:
> In general, I'd suggest not even attempting to do what you're
> apparently trying to do. As a customer, I get highly annoyed when
> some node-locked software fails after hardware upgrade, and I'll do
> just about anything to repair the situatio
>On 9/4/07, James Carlson <[EMAIL PROTECTED]> wrote:
>> In general, I'd suggest not even attempting to do what you're
>> apparently trying to do. As a customer, I get highly annoyed when
>> some node-locked software fails after hardware upgrade, and I'll do
>> just about anything to repair the si
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
oh! i see~
it's a really useful trick.
thank you, James
btw, _Locking for MT_, is vmem's internal lock schema expensive?
compared with a single global mutex assigned with the 'cur_value' .
Regards,
TJ
2007/9/5, James Carlson <[EMAIL PROTECTED]>:
>
> 陶捷 TaoJie writes:
> > In dtrace.c, function
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
I was hanging out on the perl developer's IRC channel today, and the
topic of providing dtrace support for perl came up, specifically how to
provide a ustack helper. I'd already read John Levon's blog post on how
he did this for python
(http://blogs.sun.com/levon/entry/python_and_dtrace_in_build),
> I was hanging out on the perl developer's IRC channel today, and the
> topic of providing dtrace support for perl came up, specifically how to
> provide a ustack helper. I'd already read John Levon's blog post on how
> he did this for python
> (http://blogs.sun.com/levon/entry/python_and_dtrace
Bryan Cantrill wrote:
>> If the perl interpreter detects it is running under dtrace [ ... ]
>
> That's the essence of the problem (or at least a substantial component
> of it) -- and the reason for my assertion that ustack helpers are currently
> impossible for environments like Perl: Perl isn't
On Wed, 2007-09-05 at 09:30 -0400, James Carlson wrote:
> The vmem module uses a mutex per vmem_t, which means it should be the
> same as the 'cur_value' approach. See $SRC/uts/common/os/vmem.c.
But see also the "quantum caching" description in section 1.8 of the
block comment; allocations made f
> > I really think the better route here is to have an is-enabled probe on,
> > say, Perl function entry and return that collects a stack. This will allow
> > one to get some of the benefit of the ustack helper (and indeed, all of the
> > benefit if one is debugging Perl exclusively), without hav
Is trying to access a typed argument from a USDT probe allowed?
I have a script that does "printf("%s\n", copyinstr(args[0]->ci_protocol);" and
I get the error message of "dtrace: failed to compile script mpiconn.d: line
12: failed to resolve translated type for args[0]"?
--td
--
This message
You can certainly access typed arguments from USDT probes. Can you send
the full script? If you're using the conninfo_t you may want to take a look
at what I did in the iSCSI target provider and some scripts that Brendan
Gregg wrote that use the provider.
Adam
On Wed, Sep 05, 2007 at 12:16:50PM -
> >From the output, "fbt::bcmp:entry" probe is actived for several times,
> but "fbt::bcmp:return" only 1 time. So the function entries and returns
> are not balanced at all.
This is indeed confusing. If you take a look at how bcmp is compiled on SPARC
you'll notice that it contains a backward bra
I recently did a backport of a couple of networking bug fixes from s10x_u4_b6
to s10x_u3_b10. I patched just /platform/i86pc/kernel/unix and
/platform/i86pc/kernel/amd64/unix in my existing u3 OS image and I'm seeing
this dtrace problem when running any dtrace script:
NODE hcb101 ~ $ ./tcpstat.
Hi Mike,
By replacing those binaries without generating them using the methodology
used for Solaris updates you've created a situation where the CTF (type)
data is effectively corrupt. Contact the Solaris update team for the
correct way to generate those one-off patches.
If you just want to work
Hi John,
I wouldn't get too hung up on what appears in the function field when
listing probes. Users are going to look at your documentation about what
probes to use. Also, if a probe of a given name appears in several functions,
it may be useful to be able to specify just one of those by includin
G'Day Mike,
On Wed, Sep 05, 2007 at 04:24:56PM -0700, Michael Goff wrote:
> I recently did a backport of a couple of networking bug fixes from s10x_u4_b6
> to s10x_u3_b10. I patched just /platform/i86pc/kernel/unix and
> /platform/i86pc/kernel/amd64/unix in my existing u3 OS image and I'm seeing
On Thu, Aug 30, 2007 at 01:29:40PM -0400, Dan McDonald wrote:
> On Thu, Aug 30, 2007 at 10:18:22AM -0700, Joseph Freemaker wrote:
> > Want to capture (for specific port #s) the loopback interface (lo0) tcp
> > message flow with the complete message body.
> >
> > Is this possible with DTrace?
>
G'Day Folks,
Plans to update the DTraceTools (DTraceToolkit)? yes. Development has
been happening, but I haven't wanted to upload a new version without
addressing the tcp* scripts first. somehow. They have exposed an issue
with versioning of unstable scripts and supported OSes, which I'll use
this
Thanks very much! I see. :)
I also suspect that "bcmp" is a leaf procedure, and the first
instruction is branched back to.
At first, I think I am confused with leaf procedure and tail call maybe.
Best regards,
Jia
-Original Message-
From: Adam Leventhal
Sent: 2007?09?06? 06:14
>From
Re: not enough test servers
Can't Dtrace testing and development be done on virtual machines?
Doesn't Dtrace behave the same on a Solaris 10 virtual machine (eg VMWare's
free server?) - and yes as far as I know there is not currently a way to
create a Sparc VM, but x86 based OSes are well represent
G'Day,
On Wed, Sep 05, 2007 at 08:07:25PM -0700, Fletcher Cocquyt wrote:
> Re: not enough test servers
> Can't Dtrace testing and development be done on virtual machines?
To an extent, yes (Rich Lowe just suggested it to me too :).
I can't immediately think of a case where a stable provider prob
Brendan -
Xen might be another answer to this issue. :)
I'm using Xen now, as a Solaris Dom0 and have multiple (either HVM and
or Paravirtualized) Solarii running on that box. (Also windows *shudder*
and Ubuntu)
Again - Does not help for the specific hardware cases, but might be an
answer to
Greeting All
I just wanna clarify basic concept about the two io probes (start) &
(wait-start).
Does (wait-start) do the required data transfer specified in args[0]->b_count
right before the associated (wait-done) fires !!
OR does the two associated probes (wait-start & wait-done) indicate a w
At the rate the world is going VM - the relevance of dtrace (code & kernel &
(where does the hypervisor fit?)) could be considered in jeopardy of being
marginalized.
The way to combat this is to come up with a coherent strategy - adapt - test
against those tools - incorporate the hypervisors
BTW,
26 matches
Mail list logo
