| Message ID | 20201124112054.106960-2-wangkefeng.wang@huawei.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] riscv: Add dump stack in show_regs | expand |
On Tue, Nov 24, 2020 at 3:17 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > > Using printk directly and align the printing formats. > Why switch to printk ? IIRC, pr_* is preferred over printk for any new code. > Before: > epc: ffffffe0008dc23a ra : ffffffe0008dc238 sp : ffffffe081ddbd80 gp : ffffffe0010e2c70 tp : ffffffe0800d47c0 t0 : ffffffe001018620 > t1 : 0000000000000064 t2 : 000000000000000a s0 : ffffffe081ddbda0 s1 : 0000000000000270 a0 : 000000000000002e a1 : ffffffe000baaf90 > a2 : 0000000000000010 a3 : 0000000000000001 a4 : 1db93e333d1e1200 a5 : 1db93e333d1e1200 a6 : 0000000000000030 a7 : ffffffffffffffff > s2 : 0000000000000000 s3 : ffffffe000b9ac80 s4 : ffffffe081d9f000 s5 : 0000000000000048 s6 : 000000000000000c s7 : ffffffe081ddbe80 > s8 : 0000000000000000 s9 : 00000000000b1688 s10: 0000000000099dc8 s11: 0000003fffbd9fa2 t3 : 1db93e333d1e1200 t4 : 0000000000000002 > t5 : 0000003ff778eac8 t6 : ffffffe081ddbac8status: 0000000000000120 badaddr: 0000000000000000 cause: 000000000000000d > > After: > epc: ffffffe0008dc23e ra : ffffffe0008dc23c sp : ffffffe08221bd80 > gp : ffffffe0010e2c70 tp : ffffffe081cb1ec0 t0 : ffffffe001018620 > t1 : 0000000000000064 t2 : 000000000000000a s0 : ffffffe08221bda0 > s1 : 0000000000000270 a0 : 000000000000002e a1 : ffffffe000baafb8 > a2 : 0000000000000010 a3 : 0000000000000001 a4 : eee4a3de5cb81700 > a5 : eee4a3de5cb81700 a6 : 0000000000000030 a7 : ffffffffffffffff > s2 : 0000000000000000 s3 : ffffffe000b9aca8 s4 : ffffffe081d52000 > s5 : 0000000000000048 s6 : 000000000000000c s7 : ffffffe08221be80 > s8 : 0000000000000000 s9 : 00000000000b1688 s10: 0000000000099dc8 > s11: 0000003fffe33fa2 t3 : eee4a3de5cb81700 t4 : 0000000000000002 > t5 : 0000003fcc454ac8 t6 : ffffffe08221bac8 > status: 0000000000000120 badaddr: 0000000000000000 cause: 000000000000000d > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> > --- > arch/riscv/kernel/process.c | 24 ++++++++++++------------ > 1 file changed, 12 insertions(+), 12 deletions(-) > > diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c > index e41b733abeaa..2119d49feea5 100644 > --- a/arch/riscv/kernel/process.c > +++ b/arch/riscv/kernel/process.c > @@ -44,30 +44,30 @@ void __show_regs(struct pt_regs *regs) > { > show_regs_print_info(KERN_DEFAULT); > > - pr_cont("epc: " REG_FMT " ra : " REG_FMT " sp : " REG_FMT "\n", > + printk("epc: " REG_FMT " ra : " REG_FMT " sp : " REG_FMT "\n", > regs->epc, regs->ra, regs->sp); > - pr_cont(" gp : " REG_FMT " tp : " REG_FMT " t0 : " REG_FMT "\n", > + printk("gp : " REG_FMT " tp : " REG_FMT " t0 : " REG_FMT "\n", > regs->gp, regs->tp, regs->t0); > - pr_cont(" t1 : " REG_FMT " t2 : " REG_FMT " s0 : " REG_FMT "\n", > + printk("t1 : " REG_FMT " t2 : " REG_FMT " s0 : " REG_FMT "\n", > regs->t1, regs->t2, regs->s0); > - pr_cont(" s1 : " REG_FMT " a0 : " REG_FMT " a1 : " REG_FMT "\n", > + printk("s1 : " REG_FMT " a0 : " REG_FMT " a1 : " REG_FMT "\n", > regs->s1, regs->a0, regs->a1); > - pr_cont(" a2 : " REG_FMT " a3 : " REG_FMT " a4 : " REG_FMT "\n", > + printk("a2 : " REG_FMT " a3 : " REG_FMT " a4 : " REG_FMT "\n", > regs->a2, regs->a3, regs->a4); > - pr_cont(" a5 : " REG_FMT " a6 : " REG_FMT " a7 : " REG_FMT "\n", > + printk("a5 : " REG_FMT " a6 : " REG_FMT " a7 : " REG_FMT "\n", > regs->a5, regs->a6, regs->a7); > - pr_cont(" s2 : " REG_FMT " s3 : " REG_FMT " s4 : " REG_FMT "\n", > + printk("s2 : " REG_FMT " s3 : " REG_FMT " s4 : " REG_FMT "\n", > regs->s2, regs->s3, regs->s4); > - pr_cont(" s5 : " REG_FMT " s6 : " REG_FMT " s7 : " REG_FMT "\n", > + printk("s5 : " REG_FMT " s6 : " REG_FMT " s7 : " REG_FMT "\n", > regs->s5, regs->s6, regs->s7); > - pr_cont(" s8 : " REG_FMT " s9 : " REG_FMT " s10: " REG_FMT "\n", > + printk("s8 : " REG_FMT " s9 : " REG_FMT " s10: " REG_FMT "\n", > regs->s8, regs->s9, regs->s10); > - pr_cont(" s11: " REG_FMT " t3 : " REG_FMT " t4 : " REG_FMT "\n", > + printk("s11: " REG_FMT " t3 : " REG_FMT " t4 : " REG_FMT "\n", > regs->s11, regs->t3, regs->t4); > - pr_cont(" t5 : " REG_FMT " t6 : " REG_FMT "\n", > + printk("t5 : " REG_FMT " t6 : " REG_FMT "\n", > regs->t5, regs->t6); > > - pr_cont("status: " REG_FMT " badaddr: " REG_FMT " cause: " REG_FMT "\n", > + printk("status: " REG_FMT " badaddr: " REG_FMT " cause: " REG_FMT "\n", > regs->status, regs->badaddr, regs->cause); > } > void show_regs(struct pt_regs *regs) > -- > 2.26.2 > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
+ John On 2020/11/26 6:58, Atish Patra wrote: > On Tue, Nov 24, 2020 at 3:17 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >> Using printk directly and align the printing formats. >> > Why switch to printk ? IIRC, pr_* is preferred over printk for any new code. The stack output is strange, that is why I move to printk, and the old kernel looks good. after some test, I fould first bad commit: [cfe2790b163acdc9c058a63bff310923e84a16b4] printk: move printk_info into separate array Hi John, there is printk-rework from you in v5.10-rc1, could you check it ? Thanks > >> Before: >> epc: ffffffe0008dc23a ra : ffffffe0008dc238 sp : ffffffe081ddbd80 gp : ffffffe0010e2c70 tp : ffffffe0800d47c0 t0 : ffffffe001018620 >> t1 : 0000000000000064 t2 : 000000000000000a s0 : ffffffe081ddbda0 s1 : 0000000000000270 a0 : 000000000000002e a1 : ffffffe000baaf90 >> a2 : 0000000000000010 a3 : 0000000000000001 a4 : 1db93e333d1e1200 a5 : 1db93e333d1e1200 a6 : 0000000000000030 a7 : ffffffffffffffff >> s2 : 0000000000000000 s3 : ffffffe000b9ac80 s4 : ffffffe081d9f000 s5 : 0000000000000048 s6 : 000000000000000c s7 : ffffffe081ddbe80 >> s8 : 0000000000000000 s9 : 00000000000b1688 s10: 0000000000099dc8 s11: 0000003fffbd9fa2 t3 : 1db93e333d1e1200 t4 : 0000000000000002 >> t5 : 0000003ff778eac8 t6 : ffffffe081ddbac8status: 0000000000000120 badaddr: 0000000000000000 cause: 000000000000000d >> >> After: >> epc: ffffffe0008dc23e ra : ffffffe0008dc23c sp : ffffffe08221bd80 >> gp : ffffffe0010e2c70 tp : ffffffe081cb1ec0 t0 : ffffffe001018620 >> t1 : 0000000000000064 t2 : 000000000000000a s0 : ffffffe08221bda0 >> s1 : 0000000000000270 a0 : 000000000000002e a1 : ffffffe000baafb8 >> a2 : 0000000000000010 a3 : 0000000000000001 a4 : eee4a3de5cb81700 >> a5 : eee4a3de5cb81700 a6 : 0000000000000030 a7 : ffffffffffffffff >> s2 : 0000000000000000 s3 : ffffffe000b9aca8 s4 : ffffffe081d52000 >> s5 : 0000000000000048 s6 : 000000000000000c s7 : ffffffe08221be80 >> s8 : 0000000000000000 s9 : 00000000000b1688 s10: 0000000000099dc8 >> s11: 0000003fffe33fa2 t3 : eee4a3de5cb81700 t4 : 0000000000000002 >> t5 : 0000003fcc454ac8 t6 : ffffffe08221bac8 >> status: 0000000000000120 badaddr: 0000000000000000 cause: 000000000000000d >> >> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
+Petr On 2020-11-26, Kefeng Wang <wangkefeng.wang@huawei.com> wrote: > On 2020/11/26 6:58, Atish Patra wrote: >> On Tue, Nov 24, 2020 at 3:17 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >>> Using printk directly and align the printing formats. >>> >> Why switch to printk ? IIRC, pr_* is preferred over printk for any new code. > > The stack output is strange, that is why I move to printk, and the old > kernel looks good. This is just a quick response to let you know I can reproduce the issue and I am investigating. @Petr: The proposed change and output difference is here [0]. John Ogness [0] http://lists.infradead.org/pipermail/linux-riscv/2020-November/003320.html
On 2020-11-26, John Ogness <john.ogness@linutronix.de> wrote: > On 2020-11-26, Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >> On 2020/11/26 6:58, Atish Patra wrote: >>> On Tue, Nov 24, 2020 at 3:17 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >>>> Using printk directly and align the printing formats. >>>> >>> Why switch to printk ? IIRC, pr_* is preferred over printk for any new code. >> >> The stack output is strange, that is why I move to printk, and the old >> kernel looks good. > > This is just a quick response to let you know I can reproduce the issue > and I am investigating. > > @Petr: The proposed change and output difference is here [0]. This is a bug in continuous line handling. I have posted [0] a fix to LKML. Note that a pr_cont() message with a trailing newline will "terminate" the continous line so that it can no longer be continued. Having a bunch of: pr_cont("...\n"); lines is technically wrong. If you really want the full block to be a single message, put the newline at the beginning of the pr_cont() message or add some whitespace after a newline at the end. For example: pr_cont("\n...."); or pr_cont("...\n "); Although I would suggest making them separate printk calls. With CONFIG_PRINTK_CALLER it is still possible to sort out simultaneous dumps from multiple CPUs. Thank you for reporting this! John Ogness [0] https://lkml.kernel.org/r/20201126114836.14750-1-john.ogness@linutronix.de
On 2020/11/26 19:55, John Ogness wrote: > On 2020-11-26, John Ogness <john.ogness@linutronix.de> wrote: >> On 2020-11-26, Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >>> On 2020/11/26 6:58, Atish Patra wrote: >>>> On Tue, Nov 24, 2020 at 3:17 AM Kefeng Wang <wangkefeng.wang@huawei.com> wrote: >>>>> Using printk directly and align the printing formats. >>>>> >>>> Why switch to printk ? IIRC, pr_* is preferred over printk for any new code. >>> The stack output is strange, that is why I move to printk, and the old >>> kernel looks good. >> This is just a quick response to let you know I can reproduce the issue >> and I am investigating. >> >> @Petr: The proposed change and output difference is here [0]. > This is a bug in continuous line handling. I have posted [0] a fix to > LKML. Yes, it fixes the output issue. > > Note that a pr_cont() message with a trailing newline will "terminate" > the continous line so that it can no longer be continued. Having a bunch > of: > > pr_cont("...\n"); > > lines is technically wrong. If you really want the full block to be a > single message, put the newline at the beginning of the pr_cont() > message or add some whitespace after a newline at the end. For example: > > pr_cont("\n...."); > or > pr_cont("...\n "); > > Although I would suggest making them separate printk calls. With > CONFIG_PRINTK_CALLER it is still possible to sort out simultaneous dumps > from multiple CPUs. Thanks for your explanation. I will re-post patch with changelog refresh. > > Thank you for reporting this! > > John Ogness > > [0] https://lkml.kernel.org/r/20201126114836.14750-1-john.ogness@linutronix.de > . >
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c index e41b733abeaa..2119d49feea5 100644 --- a/arch/riscv/kernel/process.c +++ b/arch/riscv/kernel/process.c @@ -44,30 +44,30 @@ void __show_regs(struct pt_regs *regs) { show_regs_print_info(KERN_DEFAULT); - pr_cont("epc: " REG_FMT " ra : " REG_FMT " sp : " REG_FMT "\n", + printk("epc: " REG_FMT " ra : " REG_FMT " sp : " REG_FMT "\n", regs->epc, regs->ra, regs->sp); - pr_cont(" gp : " REG_FMT " tp : " REG_FMT " t0 : " REG_FMT "\n", + printk("gp : " REG_FMT " tp : " REG_FMT " t0 : " REG_FMT "\n", regs->gp, regs->tp, regs->t0); - pr_cont(" t1 : " REG_FMT " t2 : " REG_FMT " s0 : " REG_FMT "\n", + printk("t1 : " REG_FMT " t2 : " REG_FMT " s0 : " REG_FMT "\n", regs->t1, regs->t2, regs->s0); - pr_cont(" s1 : " REG_FMT " a0 : " REG_FMT " a1 : " REG_FMT "\n", + printk("s1 : " REG_FMT " a0 : " REG_FMT " a1 : " REG_FMT "\n", regs->s1, regs->a0, regs->a1); - pr_cont(" a2 : " REG_FMT " a3 : " REG_FMT " a4 : " REG_FMT "\n", + printk("a2 : " REG_FMT " a3 : " REG_FMT " a4 : " REG_FMT "\n", regs->a2, regs->a3, regs->a4); - pr_cont(" a5 : " REG_FMT " a6 : " REG_FMT " a7 : " REG_FMT "\n", + printk("a5 : " REG_FMT " a6 : " REG_FMT " a7 : " REG_FMT "\n", regs->a5, regs->a6, regs->a7); - pr_cont(" s2 : " REG_FMT " s3 : " REG_FMT " s4 : " REG_FMT "\n", + printk("s2 : " REG_FMT " s3 : " REG_FMT " s4 : " REG_FMT "\n", regs->s2, regs->s3, regs->s4); - pr_cont(" s5 : " REG_FMT " s6 : " REG_FMT " s7 : " REG_FMT "\n", + printk("s5 : " REG_FMT " s6 : " REG_FMT " s7 : " REG_FMT "\n", regs->s5, regs->s6, regs->s7); - pr_cont(" s8 : " REG_FMT " s9 : " REG_FMT " s10: " REG_FMT "\n", + printk("s8 : " REG_FMT " s9 : " REG_FMT " s10: " REG_FMT "\n", regs->s8, regs->s9, regs->s10); - pr_cont(" s11: " REG_FMT " t3 : " REG_FMT " t4 : " REG_FMT "\n", + printk("s11: " REG_FMT " t3 : " REG_FMT " t4 : " REG_FMT "\n", regs->s11, regs->t3, regs->t4); - pr_cont(" t5 : " REG_FMT " t6 : " REG_FMT "\n", + printk("t5 : " REG_FMT " t6 : " REG_FMT "\n", regs->t5, regs->t6); - pr_cont("status: " REG_FMT " badaddr: " REG_FMT " cause: " REG_FMT "\n", + printk("status: " REG_FMT " badaddr: " REG_FMT " cause: " REG_FMT "\n", regs->status, regs->badaddr, regs->cause); } void show_regs(struct pt_regs *regs)
Using printk directly and align the printing formats. Before: epc: ffffffe0008dc23a ra : ffffffe0008dc238 sp : ffffffe081ddbd80 gp : ffffffe0010e2c70 tp : ffffffe0800d47c0 t0 : ffffffe001018620 t1 : 0000000000000064 t2 : 000000000000000a s0 : ffffffe081ddbda0 s1 : 0000000000000270 a0 : 000000000000002e a1 : ffffffe000baaf90 a2 : 0000000000000010 a3 : 0000000000000001 a4 : 1db93e333d1e1200 a5 : 1db93e333d1e1200 a6 : 0000000000000030 a7 : ffffffffffffffff s2 : 0000000000000000 s3 : ffffffe000b9ac80 s4 : ffffffe081d9f000 s5 : 0000000000000048 s6 : 000000000000000c s7 : ffffffe081ddbe80 s8 : 0000000000000000 s9 : 00000000000b1688 s10: 0000000000099dc8 s11: 0000003fffbd9fa2 t3 : 1db93e333d1e1200 t4 : 0000000000000002 t5 : 0000003ff778eac8 t6 : ffffffe081ddbac8status: 0000000000000120 badaddr: 0000000000000000 cause: 000000000000000d After: epc: ffffffe0008dc23e ra : ffffffe0008dc23c sp : ffffffe08221bd80 gp : ffffffe0010e2c70 tp : ffffffe081cb1ec0 t0 : ffffffe001018620 t1 : 0000000000000064 t2 : 000000000000000a s0 : ffffffe08221bda0 s1 : 0000000000000270 a0 : 000000000000002e a1 : ffffffe000baafb8 a2 : 0000000000000010 a3 : 0000000000000001 a4 : eee4a3de5cb81700 a5 : eee4a3de5cb81700 a6 : 0000000000000030 a7 : ffffffffffffffff s2 : 0000000000000000 s3 : ffffffe000b9aca8 s4 : ffffffe081d52000 s5 : 0000000000000048 s6 : 000000000000000c s7 : ffffffe08221be80 s8 : 0000000000000000 s9 : 00000000000b1688 s10: 0000000000099dc8 s11: 0000003fffe33fa2 t3 : eee4a3de5cb81700 t4 : 0000000000000002 t5 : 0000003fcc454ac8 t6 : ffffffe08221bac8 status: 0000000000000120 badaddr: 0000000000000000 cause: 000000000000000d Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> --- arch/riscv/kernel/process.c | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-)