dtrace discuss - Jan 2006 - failed to resolve SS_TCP_FAST_ACCEPT

Folks,

I came across an IPv6 snv_31 network driver problem during
testing.  I can "ping" an IPv6 address, but when I try and log
on to the IPv6 address I get an RPC failure.  Not knowing much about dtrace,
I thought I would give some of the networking dtrace scripts
a try that I found here:
http://www.opensolaris.org/os/community/dtrace/dtracetoolkit/
(tcptop or any other script in the Net directory don''t work.  For those
of you internal to Sun, tcptop is temporarily here:
/net/liondra.sfbay/export/share1/DTraceToolkit-0.92/Net

These scripts work great on an s10 RR box.  But, unfortunately
on an snv_31 box, the SS_TCP_FAST_ACCEPT variable isn''t
recognized. 

  #: tcptop
  dtrace: failed to compile script /dev/fd/10: line 40: failed to resolve
  SS_TCP_FAST_ACCEPT: Unknown variable name

Is there a simple solution to this? 

Thank you.

Paul Southerby

Hi Paul,

I work in Solaris QA and recently came across this issue when
running tcpsnoop.d on recent Solaris versions.

I think SS_TCP_FAST_ACCEPT has been changed to SS_DIRECT
by a recent putback, although I was unable to isolate it. (no time!)
Changing my local copy of tcpsnoop.d to use SS_DIRECT fixed
the problem for me.

(Both constants have the same value and occupy the exact same
 line of code in tcp.c)

regards
Brian


Paul Southerby wrote:
>
> Folks,
>
> I came across an IPv6 snv_31 network driver problem during
> testing.  I can "ping" an IPv6 address, but when I try and log
> on to the IPv6 address I get an RPC failure.  Not knowing much about 
> dtrace,
> I thought I would give some of the networking dtrace scripts
> a try that I found here:
> http://www.opensolaris.org/os/community/dtrace/dtracetoolkit/
> (tcptop or any other script in the Net directory don''t work.  For
those
> of you internal to Sun, tcptop is temporarily here:
> /net/liondra.sfbay/export/share1/DTraceToolkit-0.92/Net
>
> These scripts work great on an s10 RR box.  But, unfortunately
> on an snv_31 box, the SS_TCP_FAST_ACCEPT variable isn''t
> recognized.
>  #: tcptop
>  dtrace: failed to compile script /dev/fd/10: line 40: failed to resolve
>  SS_TCP_FAST_ACCEPT: Unknown variable name
>
> Is there a simple solution to this?
> Thank you.
>
> Paul Southerby
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

That fixed it.  Thanks Brian.  Paul Southerby

Brian Keane wrote:
> Hi Paul,
>
> I work in Solaris QA and recently came across this issue when
> running tcpsnoop.d on recent Solaris versions.
>
> I think SS_TCP_FAST_ACCEPT has been changed to SS_DIRECT
> by a recent putback, although I was unable to isolate it. (no time!)
> Changing my local copy of tcpsnoop.d to use SS_DIRECT fixed
> the problem for me.
>
> (Both constants have the same value and occupy the exact same
> line of code in tcp.c)
>
> regards
> Brian
>
>
> Paul Southerby wrote:
>
>>
>> Folks,
>>
>> I came across an IPv6 snv_31 network driver problem during
>> testing.  I can "ping" an IPv6 address, but when I try and
log
>> on to the IPv6 address I get an RPC failure.  Not knowing much about 
>> dtrace,
>> I thought I would give some of the networking dtrace scripts
>> a try that I found here:
>> http://www.opensolaris.org/os/community/dtrace/dtracetoolkit/
>> (tcptop or any other script in the Net directory don''t work. 
For those
>> of you internal to Sun, tcptop is temporarily here:
>> /net/liondra.sfbay/export/share1/DTraceToolkit-0.92/Net
>>
>> These scripts work great on an s10 RR box.  But, unfortunately
>> on an snv_31 box, the SS_TCP_FAST_ACCEPT variable isn''t
>> recognized.
>>  #: tcptop
>>  dtrace: failed to compile script /dev/fd/10: line 40: failed to
resolve
>>  SS_TCP_FAST_ACCEPT: Unknown variable name
>>
>> Is there a simple solution to this?
>> Thank you.
>>
>> Paul Southerby
>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>
>
-- 
-------------------------------------------------
Paul Southerby   Phone: (650) 786-4613   x84613 (Internal)
-------------------------------------------------
    "Sun Proprietary/Confidential: Internal Use Only"
-------------------------------------------------
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-------------------------------------------------

G''Day Folks,

On Wed, 25 Jan 2006, Brian Keane wrote:
> Hi Paul,
>
> I work in Solaris QA and recently came across this issue when
> running tcpsnoop.d on recent Solaris versions.
>
> I think SS_TCP_FAST_ACCEPT has been changed to SS_DIRECT
> by a recent putback, although I was unable to isolate it. (no time!)
> Changing my local copy of tcpsnoop.d to use SS_DIRECT fixed
> the problem for me.
>
> (Both constants have the same value and occupy the exact same
>  line of code in tcp.c)
Thank you! I''ve had a few posts about this, but I don''t have
access to a
snv_31 box to actually see it in the flesh. I suspected a name had
changed. These bugs are bound to crop up whenever I write scripts that use
the fbt provider.

I was being good and #including <sys/socketvar.h> so as not to hardcode
the value of SS_TCP_FAST_ACCEPT. Maybe I should just hardcode the value
now (SS_DIRECT is the same). :)
> regards
> Brian
>
>
> Paul Southerby wrote:
[...]
> > (tcptop or any other script in the Net directory don''t work. 
For those
> > of you internal to Sun, tcptop is temporarily here:
> > /net/liondra.sfbay/export/share1/DTraceToolkit-0.92/Net
Wow, that''s really strange to see the DTraceToolkit on an internal
address. Internal addresses usually mean I can''t ever see them, but in
this case... :)

Glad you find the tcp scripts useful!

cheers,

Brendan

[Sydney, Australia]

Hi Brendan,

I think the toolkit is a great idea!

We (Solaris QA) are working on making your DTrace toolkit scripts 
(amongst others)
available for developers and ourselves to execute in parallel to 
automated and
scheduled Solaris testsuite execution.
(Also allowing testsuite users to customise scripts or create their own)

In parallel to regular testsuite logfiles we get log files from the 
dtrace scripts tracing
during test execution, which should help with test failure analysis, 
especially useful
where a tester/developer does not have exclusive access to hardware for 
analysis work.

Brian

Brendan Gregg wrote:
>G''Day Folks,
>
>On Wed, 25 Jan 2006, Brian Keane wrote:
>
>  
>
>>Hi Paul,
>>
>>I work in Solaris QA and recently came across this issue when
>>running tcpsnoop.d on recent Solaris versions.
>>
>>I think SS_TCP_FAST_ACCEPT has been changed to SS_DIRECT
>>by a recent putback, although I was unable to isolate it. (no time!)
>>Changing my local copy of tcpsnoop.d to use SS_DIRECT fixed
>>the problem for me.
>>
>>(Both constants have the same value and occupy the exact same
>> line of code in tcp.c)
>>    
>>
>
>Thank you! I''ve had a few posts about this, but I don''t
have access to a
>snv_31 box to actually see it in the flesh. I suspected a name had
>changed. These bugs are bound to crop up whenever I write scripts that use
>the fbt provider.
>
>I was being good and #including <sys/socketvar.h> so as not to
hardcode
>the value of SS_TCP_FAST_ACCEPT. Maybe I should just hardcode the value
>now (SS_DIRECT is the same). :)
>
>  
>
>>regards
>>Brian
>>
>>
>>Paul Southerby wrote:
>>    
>>
>[...]
>  
>
>>>(tcptop or any other script in the Net directory don''t
work.  For those
>>>of you internal to Sun, tcptop is temporarily here:
>>>/net/liondra.sfbay/export/share1/DTraceToolkit-0.92/Net
>>>      
>>>
>
>Wow, that''s really strange to see the DTraceToolkit on an internal
>address. Internal addresses usually mean I can''t ever see them, but
in
>this case... :)
>
>Glad you find the tcp scripts useful!
>
>cheers,
>
>Brendan
>
>[Sydney, Australia]
>
>  
>

Brain,

Sounds like a terrific idea.  We have a bunch of automated tests
we run and incorporating the DTrace tookit scripts into the testing
sounds like a terrific idea.  I''d be interested in learning more about
what you come up with while I explore the toolkit more.

Thanks for the great idea.

Regards,
Paul Southerby

Brian Keane wrote:
> Hi Brendan,
>
> I think the toolkit is a great idea!
>
> We (Solaris QA) are working on making your DTrace toolkit scripts 
> (amongst others)
> available for developers and ourselves to execute in parallel to 
> automated and
> scheduled Solaris testsuite execution.
> (Also allowing testsuite users to customise scripts or create their own)
>
> In parallel to regular testsuite logfiles we get log files from the 
> dtrace scripts tracing
> during test execution, which should help with test failure analysis, 
> especially useful
> where a tester/developer does not have exclusive access to hardware 
> for analysis work.
>
> Brian
>
> Brendan Gregg wrote:
>
>> G''Day Folks,
>>
>> On Wed, 25 Jan 2006, Brian Keane wrote:
>>
>>  
>>
>>> Hi Paul,
>>>
>>> I work in Solaris QA and recently came across this issue when
>>> running tcpsnoop.d on recent Solaris versions.
>>>
>>> I think SS_TCP_FAST_ACCEPT has been changed to SS_DIRECT
>>> by a recent putback, although I was unable to isolate it. (no
time!)
>>> Changing my local copy of tcpsnoop.d to use SS_DIRECT fixed
>>> the problem for me.
>>>
>>> (Both constants have the same value and occupy the exact same
>>> line of code in tcp.c)
>>>   
>>
>>
>> Thank you! I''ve had a few posts about this, but I
don''t have access to a
>> snv_31 box to actually see it in the flesh. I suspected a name had
>> changed. These bugs are bound to crop up whenever I write scripts 
>> that use
>> the fbt provider.
>>
>> I was being good and #including <sys/socketvar.h> so as not to
hardcode
>> the value of SS_TCP_FAST_ACCEPT. Maybe I should just hardcode the value
>> now (SS_DIRECT is the same). :)
>>
>>  
>>
>>> regards
>>> Brian
>>>
>>>
>>> Paul Southerby wrote:
>>>   
>>
>> [...]
>>  
>>
>>>> (tcptop or any other script in the Net directory don''t
work.  For
>>>> those
>>>> of you internal to Sun, tcptop is temporarily here:
>>>> /net/liondra.sfbay/export/share1/DTraceToolkit-0.92/Net
>>>>     
>>>
>>
>> Wow, that''s really strange to see the DTraceToolkit on an
internal
>> address. Internal addresses usually mean I can''t ever see
them, but in
>> this case... :)
>>
>> Glad you find the tcp scripts useful!
>>
>> cheers,
>>
>> Brendan
>>
>> [Sydney, Australia]
>>
>>  
>>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

-- 
-------------------------------------------------
Paul Southerby   Phone: (650) 786-4613   x84613 (Internal)
-------------------------------------------------
    "Sun Proprietary/Confidential: Internal Use Only"
-------------------------------------------------
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-------------------------------------------------

G''Day Paul, Brian,

On Thu, 26 Jan 2006, Paul Southerby wrote:
>
> Brain,
>
> Sounds like a terrific idea.  We have a bunch of automated tests
> we run and incorporating the DTrace tookit scripts into the testing
> sounds like a terrific idea.  I''d be interested in learning more
about
> what you come up with while I explore the toolkit more.
>
> Thanks for the great idea.
>
> Regards,
> Paul Southerby
>
> Brian Keane wrote:
>
> > Hi Brendan,
> >
> > I think the toolkit is a great idea!
> >
> > We (Solaris QA) are working on making your DTrace toolkit scripts
> > (amongst others)
> > available for developers and ourselves to execute in parallel to
> > automated and
> > scheduled Solaris testsuite execution.
> > (Also allowing testsuite users to customise scripts or create their
own)
> >
> > In parallel to regular testsuite logfiles we get log files from the
> > dtrace scripts tracing
> > during test execution, which should help with test failure analysis,
> > especially useful
> > where a tester/developer does not have exclusive access to hardware
> > for analysis work.
> >
> > Brian
> >
Most interesting.

A while ago I wrote DExplorer (it''s in the toolkit) as a tool to run to
give a broad dtrace-based view of what is happening on the system.
I need to rework DExplorer to run the 20 scripts it contains in parallel
(it currently runs sequentially).

Please post if there are other interesting statistics that developers are
interested in, and any more information about this testsuite.

Also, I am most happy that the scripts are reworked for other uses, but
make sure the newest versions are being used (I think all freeware
developers say this :-). The scripts get updated and improved over time.

cheers,

Brendan