[Bug 211821] dtrace: invalid probe specifier lockstat:::: "/usr/lib/dtrace/tcp.d", line 201: operator / requires operands of arithmetic type
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sat Aug 13 23:56:32 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211821
Bug ID: 211821
Summary: dtrace: invalid probe specifier lockstat::::
"/usr/lib/dtrace/tcp.d", line 201: operator / requires
operands of arithmetic type
Product: Base System
Version: 10.3-RELEASE
Hardware: ppc
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: freebsd at g3os.org
It seems that while dtrace knows about `hz, /usr/lib/dtrace/tcp.d does not,
which causes the following problem:
EXPECTED
--------
When I run dtrace -ln [[[provider:]module:]probe:]name I expect output like
this:
# dtrace -ln lockstat:::
ID PROVIDER MODULE FUNCTION NAME
25295 lockstat kernel mtx_lock_spin
spin-acquire
25296 lockstat kernel mtx_lock_spin spin-spin
25297 lockstat kernel mtx_unlock_spin
spin-release
...
25321 lockstat kernel sx_try_upgrade sx-upgrade
25322 lockstat kernel sx_downgrade
sx-downgrade
25323 lockstat kernel thread_lock
thread-spin
ACTUAL
------
but instead I get output like this:
dtrace -ln lockstat:::
dtrace: invalid probe specifier lockstat:::: "/usr/lib/dtrace/tcp.d", line 201:
operator / requires operands of arithmetic type
# dtrace -l by itself is not affected.
HACK/FIX
--------
In /usr/lib/dtrace/tcp.d, when I change line 201 from:
201 tcps_rto = p == NULL ? -1 : (p->t_rxtcur * 1000) /
`hz;
to:
201 tcps_rto = p == NULL ? -1 : (p->t_rxtcur * 1000) /
(int) `hz;
I get the output I expect.
My understanding is that backticks tell dtrace to use kernel variable names but
I'm not sure how to include them so that dtrace sees it.
I think hz is an int defined in sys/sys/kernel.h:
60 extern int tick; /* usec per tick (1000000 / hz) */
61 extern int hz; /* system clock's frequency */
62 extern int psratio; /* ratio: prof / stat */
and that t_rxtcur defined in sys/netinet/tcp_var.h is also an int.
202
203 int t_rxtcur; /* current retransmit value
(ticks) */
204 u_int t_maxseg; /* maximum segment size */
So I think casting to an int is reasonable.
With my hack this also works:
# dtrace -n 'BEGIN { trace(`hz); }'
dtrace: description 'BEGIN ' matched 1 probe
dtrace: buffer size lowered to 2m
CPU ID FUNCTION:NAME
0 1 :BEGIN 1000
So I conclude that dtrace knows about hz but tcp.d does not. I suspect there
is a way for tcp.d to know about kernel.h rather than do a cast, and that this
would be preferable, but I don't know how to do that.
SYSTEM INFO
-----------
I'm using an eMac (PowerPC G4).
# uname -a
FreeBSD emac.local 10.3-RELEASE FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25
05:18:20 UTC 2016
root at releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc/usr/src/sys/GENERIC
powerpc
$ dmesg
...
FreeBSD 10.3-RELEASE #0 r297264: Fri Mar 25 05:18:20 UTC 2016
root at releng1.nyi.freebsd.org:/usr/obj/powerpc.powerpc/usr/src/sys/GENERIC
powerpc
gcc version 4.2.1 20070831 patched [FreeBSD]
cpu0: Motorola PowerPC 7455 revision 3.3, 1000.29 MHz
cpu0: Features 9c000000<PPC32,ALTIVEC,FPU,MMU>
cpu0: HID0 8450c0bc<EMCP,TBEN,NAP,DPM,ICE,DCE,SGE,BTIC,LRSTK,FOLD,BHT>
real memory = 520597504 (496 MB)
...
Thank you,
- d
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list