DTrace gone quiet?

Navdeep Parhar np at FreeBSD.org
Tue Apr 16 20:14:12 UTC 2013


On 04/16/13 13:03, Ryan Stone wrote:
> On Tue, Apr 16, 2013 at 3:57 PM, Navdeep Parhar <np at freebsd.org
> <mailto:np at freebsd.org>> wrote:
> 
>     I just upgraded my kernel and userspace to head (r249552) and I notice
>     that DTrace doesn't output anything until I hit ctrl-c.  All previous
>     "hits" on the probe appear lost.  For example:
> 
>     # dtrace -n 'fbt::ether_output:entry'
>     dtrace: description 'fbt::ether_output:entry' matched 1 probe
> 
>     (No output here.  I waited a long time before the ctrl-c and I know the
>     system is actively transmitting and receiving Ethernet traffic).
> 
>     ^C
>     CPU     ID                    FUNCTION:NAME
>       9  29354               ether_output:entry
>       8  29354               ether_output:entry
>       8  29354               ether_output:entry
>       8  29354               ether_output:entry
> 
> 
>     Can anyone confirm or contradict this on a recent HEAD (around r249552
>     in my case)?
> 
>     Regards,
>     Navdeep
> 
> 
> Hm, if you run with "-x bufpolicy=switch" does it work?  It sounds as
> through the ring buffer policy is being set by default for you.  I'm not
> sure how that could happen.

No luck.

trantor:~# dtrace -x bufpolicy=switch -n 'fbt::ether_output:entry'
dtrace: description 'fbt::ether_output:entry' matched 1 probe

(long fruitless wait here)

^C
CPU     ID                    FUNCTION:NAME
  4  29354               ether_output:entry
  3  29354               ether_output:entry
  9  29354               ether_output:entry
  3  29354               ether_output:entry





More information about the freebsd-current mailing list