> On Fri, Sep 04, 2020 at 05:24:38PM +0900, Changki Kim wrote: > > Printk() meesages are the most basic and useful debug method. > > However, additional information needs in multi-processor. > > If we add messages with processor id and process name, we can find a > > problem only with messages when the problem occurs with H/W IP or CPU. > > This is very useful in narrowing down the scope of the problems. > > > > Therefore, instead of trying to help buffering, let's try to help > > reconstructing messages by saving caller information as of calling > > log_store() and adding it as "[$processor_id: $process_name: > $thread_id]" > > upon printing to consoles. > > > > Some examples for console output: > > > > [ 0.059580] [0: swapper/0: 1] CPU: All CPU(s) started at EL1i > > [ 2.153157] [5: init: 1] migov: complete to probe migov > > [ 7.441317] [4: init: 1] NET: Registered protocol family 39 > > [ 22.793389] [5: kworker/u16:1: 184] SMP: stopping secondary CPUs > > > > Signed-off-by: Changki Kim <changki....@samsung.com> > > --- > > kernel/printk/printk.c | 20 ++++++++++++++++++-- > > kernel/printk/printk_ringbuffer.h | 7 +++++++ > > lib/Kconfig.debug | 16 ++++++++++++++++ > > 3 files changed, 41 insertions(+), 2 deletions(-) > > Isn't the CPU number already present if you want it today? Why add it > again? > > thanks, > > greg k-h
CPU number isn't present now. If I enabled PRINTK_CALLER, then it is present cpu id or thread id. The config isn't always present cpu id. We need cpu id each each message. Thanks.
