[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=2I 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