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