Re: Kernel tracing options with USB subsystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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


B and H Foto and Electronics Corp.

[Linux Media]     [Video for Linux]     [Linux Input]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Free Online Dating]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]     [More Archives]

Add to Google Powered by Linux