<div dir="ltr"><div><div>I am trying to widen the information reported by the block_rq_complete() tracepoint, but am unable to get my extension to take affect. Basically, I'd like 3 additional numbers captured at that point.<br></div><div><br></div><div>So far, I've failed to succeed in this effort. As part of trying to determine what is going on, I've created a new tracepoint definition in include/trace/event/block.h which defines block_rq_complete_ex, which is just like block_rq_complete but with my additional fields. I've altered the trace_block_rq_complete() call in block/blk-core.c to be trace_block_rq_complete_ex().</div><div><br></div><div> Other than block_rq_complete being mentioned in blktrace.c (which *seems* to be unrelated to the LTTng tracing), everywhere there is a mention of block_rq_complete there is a matching mention of block_rq_complete_ex.</div><div><br></div><div>When I build a kernel (LTTng built in mode), the resulting kernel has block_rq_complete_ex text in it. When I boot it, start an LTTng session, and list the kernel tracepoints - my new tracepoint isn't listed.  If I've put a new printk in the kernel, it's output is visible. Any ideas on what I'm missing? Things I've checked:</div><div><br></div><div> - Built from a distclean'd kernel tree</div><div> - lttng is "built in" (I ran the scripts/built_in.sh script and confirmed the CONFIG_* flags</div><div> - I can enable the original block_rq_complete tracepoint and collect data through it</div><div> - If instead of having a new tracepoint I just extend the old one, the new data doesn't show up<br></div><br></div><div>It really seems like there is a cached or overriding definition of these tracepoints that I'm getting instead of what I've compiled. There are multiple kernels on the system, but I am booting the kernel I intend to.</div><div><br></div><div>Any ideas would be highly appreciated.</div><div><br></div><div> - db</div><div><br></div></div>