On Fri, Jul 12, 2013 at 07:25:59AM +0300, Kalle Valo wrote: > Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx> writes: > > > My initial list of specific trace points was something like: > > > > 1. xHCI host initialization and shutdown > > > > 2. xHCI memory allocation (dynamic ring resizing, structure alloc, etc) > > > > 3. A few individual xHCI host controller command tracepoints: > > * 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 > > > > 4. Tracepoints for all USB transfer types: > > * 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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
