[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120803223623.GB6156@kroah.com>
Date: Fri, 3 Aug 2012 15:36:23 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: "Pandita, Vikram" <vikram.pandita@...com>
Cc: Aaro Koskinen <aaro.koskinen@....fi>,
Andi Kleen <andi@...stfloor.org>, kay@...y.org,
linux-kernel@...r.kernel.org, linux-omap@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
Mike Turquette <mturquette@...aro.org>,
Vimarsh Zutshi <vimarsh.zutshi@...il.com>
Subject: Re: [PATCH v3] printk: add option to print cpu id
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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists