Hi, Austin Thank you for the patch. On Fri, Nov 1, 2024 at 5:19 PM <devel-request(a)lists.crash-utility.osci.io&gt; wrote: > > Date: Tue, 29 Oct 2024 17:32:07 +0900 > From: Austin Kim <austindh.kim(a)gmail.com&gt; > Subject: [Crash-utility] [PATCH] RISCV64: add panic signature to > panic_msg to properly display the PANIC message > To: devel(a)lists.crash-utility.osci.io > Cc: austindh.kim(a)gmail.com, austin.kim(a)lge.com > Message-ID: <20241029083207.GA30130@adminpc-PowerEdge-R7525> > Content-Type: text/plain; charset=us-ascii > > Using 'sys' command, we can view the panic message with general system > information. If we run RISCV64-based vmcore, PANIC message is not properly > displayed. > > The reason is that "Unable to handle kernel" is first printed in the kernel log > when exception occurs in the RISC-V based Linux kernel. The corresponding > kernel commit is 21733cb518471. > > Without the patch: > crash> sys > KERNEL: vmlinux [TAINTED] > DUMPFILE: vmcore > CPUS: 4 > DATE: Thu Aug 22 16:13:08 KST 2024 > UPTIME: 00:33:25 > LOAD AVERAGE: 0.07, 0.07, 0.02 > TASKS: 385 > NODENAME: starfive > RELEASE: 6.6.20+ > VERSION: #13 SMP Mon Aug 19 12:58:52 KST 2024 > MACHINE: riscv64 (unknown Mhz) > MEMORY: 4 GB > PANIC: "" > > With the patch: > crash> sys > KERNEL: vmlinux [TAINTED] > DUMPFILE: vmcore > CPUS: 4 > DATE: Thu Aug 22 16:13:08 KST 2024 > UPTIME: 00:33:25 > LOAD AVERAGE: 0.07, 0.07, 0.02 > TASKS: 385 > NODENAME: starfive > RELEASE: 6.6.20+ > VERSION: #13 SMP Mon Aug 19 12:58:52 KST 2024 > MACHINE: riscv64 (unknown Mhz) > MEMORY: 4 GB > PANIC: "Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000000" > > Signed-off-by: Austin Kim <austindh.kim(a)gmail.com&gt; > --- > task.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/task.c b/task.c > index d52ce0b..443f488 100644 > --- a/task.c > +++ b/task.c > @@ -6330,6 +6330,7 @@ static const char* panic_msg[] = { > "[Hardware Error]: ", > "Bad mode in ", > "Oops: ", > + "Unable to handle kernel access ", I would tend to search the panic keywords again as below, which can cover both riscv64 and aarch64 cases. diff --git a/task.c b/task.c index c131cc32067d..9613adebab57 100644 --- a/task.c +++ b/task.c @@ -6392,6 +6392,9 @@ get_panicmsg(char *buf) get_symbol_data("sysrq_pressed", sizeof(int), &msg_found); break; } + + /* try to search panic string with panic keywords*/ + search_panic_task_by_keywords(buf, &msg_found); } found: What do you think? I haven't tested this one, not sure if it can work for you, could you please try it? Tao, can we also do a regression test to double check if there are any risks?

Thanks Lianbo > > }; > > #define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0])) > -- > 2.17.1

Hello Lianbo, 2024년 11월 6일 (수) 오후 12:53, lijiang <lijiang(a)redhat.xn--com&gt;-4f21ay07k 작성: > > Hi, Austin > Thank you for the patch. > > On Fri, Nov 1, 2024 at 5:19 PM <devel-request(a)lists.crash-utility.osci.io&gt; wrote: >> >> Date: Tue, 29 Oct 2024 17:32:07 +0900 >> From: Austin Kim <austindh.kim(a)gmail.com&gt; >> Subject: [Crash-utility] [PATCH] RISCV64: add panic signature to >> panic_msg to properly display the PANIC message >> To: devel(a)lists.crash-utility.osci.io >> Cc: austindh.kim(a)gmail.com, austin.kim(a)lge.com >> Message-ID: <20241029083207.GA30130@adminpc-PowerEdge-R7525> >> Content-Type: text/plain; charset=us-ascii >> >> Using 'sys' command, we can view the panic message with general system >> information. If we run RISCV64-based vmcore, PANIC message is not properly >> displayed. >> >> The reason is that "Unable to handle kernel" is first printed in the kernel log >> when exception occurs in the RISC-V based Linux kernel. The corresponding >> kernel commit is 21733cb518471. >> >> Without the patch: >> crash> sys >> KERNEL: vmlinux [TAINTED] >> DUMPFILE: vmcore >> CPUS: 4 >> DATE: Thu Aug 22 16:13:08 KST 2024 >> UPTIME: 00:33:25 >> LOAD AVERAGE: 0.07, 0.07, 0.02 >> TASKS: 385 >> NODENAME: starfive >> RELEASE: 6.6.20+ >> VERSION: #13 SMP Mon Aug 19 12:58:52 KST 2024 >> MACHINE: riscv64 (unknown Mhz) >> MEMORY: 4 GB >> PANIC: "" >> >> With the patch: >> crash> sys >> KERNEL: vmlinux [TAINTED] >> DUMPFILE: vmcore >> CPUS: 4 >> DATE: Thu Aug 22 16:13:08 KST 2024 >> UPTIME: 00:33:25 >> LOAD AVERAGE: 0.07, 0.07, 0.02 >> TASKS: 385 >> NODENAME: starfive >> RELEASE: 6.6.20+ >> VERSION: #13 SMP Mon Aug 19 12:58:52 KST 2024 >> MACHINE: riscv64 (unknown Mhz) >> MEMORY: 4 GB >> PANIC: "Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000000" >> >> Signed-off-by: Austin Kim <austindh.kim(a)gmail.com&gt; >> --- >> task.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/task.c b/task.c >> index d52ce0b..443f488 100644 >> --- a/task.c >> +++ b/task.c >> @@ -6330,6 +6330,7 @@ static const char* panic_msg[] = { >> "[Hardware Error]: ", >> "Bad mode in ", >> "Oops: ", >> + "Unable to handle kernel access ", > > > I would tend to search the panic keywords again as below, which can cover both riscv64 and aarch64 cases. > > diff --git a/task.c b/task.c > index c131cc32067d..9613adebab57 100644 > --- a/task.c > +++ b/task.c > @@ -6392,6 +6392,9 @@ get_panicmsg(char *buf) > get_symbol_data("sysrq_pressed", sizeof(int), &msg_found); > break; > } > + > + /* try to search panic string with panic keywords*/ > + search_panic_task_by_keywords(buf, &msg_found); > }

> > found: > > > What do you think? I haven't tested this one, not sure if it can work for you, could you please try it? Thank you for the positive feedback on the patch and for sharing another great idea. I tested the patch you suggested, and it worked well on my side. Here’s the crash message: crash> sys | grep PANIC PANIC: "Unable to handle kernel access to user memory without uaccess routines at virtual address 0000000000000000" This new patch is useful not only for RISC-V but also for a wider range of architectures, and it seems like a better approach than modifying panic_msg[]. Best regards, Austin Kim > Tao, can we also do a regression test to double check if there are any risks? > > Thanks > Lianbo > > >> >> }; >> >> #define ARRAY_SIZE(a) (sizeof (a) / sizeof ((a)[0])) >> -- >> 2.17.1