Paul Southerby
2006-Jan-25 22:19 UTC
[dtrace-discuss] 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
Paul Southerby
2006-Jan-25 22:38 UTC
[dtrace-discuss] failed to resolve SS_TCP_FAST_ACCEPT
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/NetWow, 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] > > >
Paul Southerby
2006-Jan-26 18:02 UTC
[dtrace-discuss] failed to resolve SS_TCP_FAST_ACCEPT
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