Thread (12 messages) flat view 12 messages, 6 authors, 2012-08-06

[PATCH v3] printk: add option to print cpu id

From: Pandita, Vikram <hidden>
Date: 2012-08-03 22:48:50
Also in: linux-omap, lkml

On Fri, Aug 3, 2012 at 3:36 PM, Greg KH [off-list ref] wrote:
On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote:
quoted
quoted
quoted
This was something that got used internally and helped at times.
Could you have used the trace point instead?
As i understood the trace_prink(), one would need to modify existing
printk -> trace_printk. Is my understanding correct?
No, you should just be able to watch the tracepoint, right?
yes.
Assumption being you know _EXACTLY_ what code piece to watch for.
Which may not be the case all times.
quoted
Most of the times the problem exhibits as a random hang, without having a clue
which code to modify. That time one generic defconfig global switch is
your first tool.

Other issue i found, using this patch, that on multi-core ARM systems,
almost 99% of times, IRQ's are handled by CPU0,
even if CPU0 was really busy and other CPU's were free. I am yet to
understand a good reason why.
Can't you see that from /proc/interrupts today?
You are right that was the next step i did and that shows the problem as well.
The point i was trying to make, with printk showing cpu-id, there are
problems in system that could get highlighted,
given printk almost always runs with linux kernel.
quoted
this patch also helped in other areas as mentioned in the thread
http://marc.info/?l=linux-omap&m=134401269106619&w=2
I still don't understand how adding the cpu number to printk enabled you
to find any problem like this.  Can't you just add the cpu number to the
printk messages you care about for your specific hardware?
The assumption here is that a developer knows well enough, which code
to modify for logging.
I my experience, that is not true most of the times. A global
defconfig switch is much easier to enable.

Eg: when i have some timing related issue, first thing i go for is to
enable PRINTK_TIME, without even
having to think about the erring code. Then time-stamps lead to bad code.

That is the same though process behind the cpu-id in printk.

greg k-h
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help