Help adding trace events to xHCI

[Sarah Sharp]

1. xHCI host initialization and shutdown
2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
* status only for all completed commands
* Address Device command status and output
* Configure Endpoint and Evaluate Context output
* individual trace points for other xHCI commands
* Control TX output (only for non-successful transfers)
* Bulk TX
* Interrupt TX
* Isoc TX
5. URB cancellation
And probably more. Basically, I want to be able to control what gets
printed, based on where I think the xHCI bug might be. Does that sound
reasonable?

Instead of individual trace points for command I would recommend to
consider just pushing the whole command buffer to the trace point and
parse the command in trace-cmd plugin in user space. Kernel code would
be simpler that way.

Thanks for the suggestion. I'm not familiar with all the userspace
tools for trace events, so I didn't know about the command parser. Is
there documentation or a list of resources for all the userspace trace
event plugins? If so, can you give us a pointer to it?

Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Steven Rostedt]

Post by Sarah Sharp
Thanks for the suggestion. I'm not familiar with all the userspace
tools for trace events, so I didn't know about the command parser. Is
there documentation or a list of resources for all the userspace trace
event plugins? If so, can you give us a pointer to it?

Currently the plugins only exist in trace-cmd. But there's going to be
work done to get them into the kernel tools directory. I was just
talking with Jiri about this today. Perf will require it.

trace-cmd repo is here:

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Jiri Olsa]

Post by Steven Rostedt

Post by Sarah Sharp
Thanks for the suggestion. I'm not familiar with all the userspace
tools for trace events, so I didn't know about the command parser. Is
there documentation or a list of resources for all the userspace trace
event plugins? If so, can you give us a pointer to it?

Currently the plugins only exist in trace-cmd. But there's going to be
work done to get them into the kernel tools directory. I was just
talking with Jiri about this today. Perf will require it.

hi,
I made initial backport but got distracted.. ;-)
I'll refresh those patches and resend them out soon..

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Mathieu Desnoyers]

Post by Sarah Sharp

1. xHCI host initialization and shutdown
2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc)
* status only for all completed commands
* Address Device command status and output
* Configure Endpoint and Evaluate Context output
* individual trace points for other xHCI commands
* Control TX output (only for non-successful transfers)
* Bulk TX
* Interrupt TX
* Isoc TX
5. URB cancellation
And probably more. Basically, I want to be able to control what gets
printed, based on where I think the xHCI bug might be. Does that sound
reasonable?

Instead of individual trace points for command I would recommend to
consider just pushing the whole command buffer to the trace point and
parse the command in trace-cmd plugin in user space. Kernel code would
be simpler that way.

Thanks for the suggestion. I'm not familiar with all the userspace
tools for trace events, so I didn't know about the command parser. Is
there documentation or a list of resources for all the userspace trace
event plugins? If so, can you give us a pointer to it?

(CCing lttng-dev)

You might want to try out LTTng-UST. It provides TRACEPOINT_EVENT() and
tracepoint() for user-space instrumentation. See:

- https://lttng.org/files/doc/man-pages/man3/lttng-ust.3.html
- http://lttng.org

Thanks,

Mathieu

Post by Sarah Sharp
Sarah Sharp
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Mark Wielaard]

Hi Mathieu,

Post by Mathieu Desnoyers

Post by Sarah Sharp
Thanks for the suggestion. I'm not familiar with all the userspace
tools for trace events, so I didn't know about the command parser. Is
there documentation or a list of resources for all the userspace trace
event plugins? If so, can you give us a pointer to it?

You might want to try out LTTng-UST. It provides TRACEPOINT_EVENT() and
- https://lttng.org/files/doc/man-pages/man3/lttng-ust.3.html

Is that build on the <sys/sdt.h> ust probe points as embedded in glibc
for example that gdb and systemtap use to access user space trace
points? Can tools use lttng-ust and <sys/sdt.h> tracepoints
interchangeably by parsing the ELF notes described in
http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation

Thanks,

Mark
--
To unsubscribe from this list: send the line "unsubscribe linux-trace-users" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Mathieu Desnoyers]

Post by Mark Wielaard
Hi Mathieu,

Post by Mathieu Desnoyers

Post by Sarah Sharp
Thanks for the suggestion. I'm not familiar with all the userspace
tools for trace events, so I didn't know about the command parser. Is
there documentation or a list of resources for all the userspace trace
event plugins? If so, can you give us a pointer to it?

You might want to try out LTTng-UST. It provides TRACEPOINT_EVENT() and
- https://lttng.org/files/doc/man-pages/man3/lttng-ust.3.html

Is that build on the <sys/sdt.h> ust probe points as embedded in glibc
for example that gdb and systemtap use to access user space trace
points?

LTTng-UST tracepoints are not built on sdt.h, but they can optionally
emit sdt.h instrumentation. All you need to do is run:

./configure --with-sdt

when configuring lttng-ust, and after a make install, sdt.h
STAP_PROBEV() will be emitted whenever a lttng-ust tracepoint() macro is
used in the system.

Post by Mark Wielaard
Can tools use lttng-ust and <sys/sdt.h> tracepoints
interchangeably by parsing the ELF notes described in
http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation

Since lttng-ust tracepoints emit sdt.h instrumentation, yes. However,
please note that the reverse is not possible: sdt.h instrumentation does
not allow tracing with LTTng-UST.

Thanks,

Mathieu

Post by Mark Wielaard
Thanks,
Mark

[Kalle Valo]

Post by Sarah Sharp

Instead of individual trace points for command I would recommend to
consider just pushing the whole command buffer to the trace point and
parse the command in trace-cmd plugin in user space. Kernel code would
be simpler that way.

Thanks for the suggestion. I'm not familiar with all the userspace
tools for trace events, so I didn't know about the command parser. Is
there documentation or a list of resources for all the userspace trace
event plugins? If so, can you give us a pointer to it?

For ath6kl I started writing (but did not finish yet) a simple python
plugin for trace-cmd. I really like the idea of implementing of
implementing the parser with python, it's so much faster and more
convenient. I haven't published the plugin yet so that's not going to
help you right now.

But trace-cmd documentation about python plugins should give some ideas
how to use python:

https://git.kernel.org/cgit/linux/kernel/git/rostedt/trace-cmd.git/tree/Documentation/README.PythonPlugin

And as usual, Johannes is a good source of information ;)