Hello Greg, On Fri, Jul 20, 2012 at 11:30 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > A: No. > Q: Should I include quotations after my reply? > > http://daringfireball.net/2007/07/on_top > > On Fri, Jul 20, 2012 at 10:14:57PM +0530, Balakumar wrote: >> Hi Greg, >> >> When it comes to embedded device cases, I feel that the options are >> just left with debug messages. It becomes really difficult to debug >> some SMP specific issues, thread deadlocks etc. I felt that, using >> trace events, we could effectively log some of those specific data >> without the penalty of compromising latency which happens with >> printks. > > Again, where in the usb core are we using printks for tracing? We don't > do that except for the "usb snoop" mode for usbfs, and that's there > primarily to help reverse engineer other operating systems, and it works > pretty well for that task. I am sorry that I did not make myself clear with the printks. As you have mentioned the core or the gadget framework does not have printk. But, during debugging, to understand the control flow, I would be adding some printk at the desired locations. During a data transfer this printk would get hit a number of timer and floods the dmesg. To quote an example, the request getting queued to the controller, the stats regarding that request (actual length, total length, status) etc. Some gadget drivers try to queue data from both the application and the irq context. (e.g. u_serial.c) In such cases, I felt that an appropriately placed trace event would log on the task which is queuing that request, the CPU id (if applicable) plus the additional parameter we request to log during that time. I feel that such information getting logged into the trace ring buffer would be helpful during a crash/hang case. > >> usbmon is perfect, but USB-centric. The background behind my queries >> was that, is there someway we could trace out whats happening in the >> USB which also contains the kernel information, like the cpu%d it is >> running, the task context etc. >> >> I am fairly new to linux, so please correct me if I got my >> understanding wrong :) > > usbmon is usb-centric, as that is what it was written for. What exactly > are you wanting to see here that could help you out more than what > usbmon provides? > > usbmon is there to monitor the flow of data across the usb wire, not to > do any performance testing or really care about anything outside of the > USB core at all. If you need/want more, we will be glad to work to > provide it, but we need specific use-cases and examples to work off of. > > So, to start with, what specific problems are you having with USB on > your platform that you need better tracing information for to help > resolve the issues? I am working on a basic framework now which would try to log such data using the trace events. I will try to get some trace logs (+ relevant dmesg and usbmon logs) ASAP, so that you can help me. Many Thanks, ~Bala > > thanks, > > greg k-h -- 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
