On Fri, Aug 03, 2012 at 03:25:17PM -0700, Pandita, Vikram wrote: > >> 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? > 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? > 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? greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
