On 3.18.3-201.fc21.x86_64 with HEAD systemtap, I'm seeing this: ==== # rm -rf ~/.systemtap/cache # stap --disable-cache -p4 -e 'probe kernel.trace("net_dev_queue") { exit() }' semantic error: while resolving probe point: identifier 'kernel' at <input>:1:7 source: probe kernel.trace("net_dev_queue") { exit() } ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] # stap -p4 -e 'probe kernel.trace("net_dev_queue") { exit() }' /home/dsmith/.systemtap/cache/32/stap_32123f202c07308478d5a4b63bd3f3fb_1013.ko ==== So, if you disable the cache, the net_dev_queue tracepoint cannot be found. The same thing happens if you use 'net:net_dev_queue": ==== # rm -rf ~/.systemtap/cache/ # stap --disable-cache -p4 -e 'probe kernel.trace("net:net_dev_queue") { exit() }' semantic error: while resolving probe point: identifier 'kernel' at <input>:1:7 source: probe kernel.trace("net:net_dev_queue") { exit() } ^ semantic error: no match Pass 2: analysis failed. [man error::pass2] # stap -p4 -e 'probe kernel.trace("net:net_dev_queue") { exit() }' /home/dsmith/.systemtap/cache/39/stap_395be0216c36fbd440e26cf3ceb7745a_1017.ko ====
Created attachment 8139 [details] Always use new tracequery modules directly How does this look?
(In reply to Josh Stone from comment #1) > Created attachment 8139 [details] > Always use new tracequery modules directly > > How does this look? I'm not really familiar with that part of the code, but it looks reasonable to me.
commit 40d78ace0f1d4eff2bdfc8b940ad939d39274b6e