All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Conor.Dooley@microchip.com>
To: <xianting.tian@linux.alibaba.com>, <paul.walmsley@sifive.com>,
	<palmer@dabbelt.com>, <aou@eecs.berkeley.edu>,
	<anup@brainfault.org>, <heiko@sntech.de>, <guoren@kernel.org>,
	<mick@ics.forth.gr>, <alexandre.ghiti@canonical.com>,
	<bhe@redhat.com>, <vgoyal@redhat.com>, <dyoung@redhat.com>,
	<corbet@lwn.net>, <Conor.Dooley@microchip.com>
Cc: <kexec@lists.infradead.org>, <linux-doc@vger.kernel.org>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<crash-utility@redhat.com>, <huanyi.xj@alibaba-inc.com>,
	<heinrich.schuchardt@canonical.com>, <k-hagio-ab@nec.com>,
	<hschauhan@nulltrace.org>, <yixun.lan@gmail.com>
Subject: Re: [PATCH V5 4/6] RISC-V: Fixup getting correct current pc
Date: Tue, 9 Aug 2022 21:13:05 +0000	[thread overview]
Message-ID: <3fbfaa49-8ee9-a65c-133b-d0f072f0eb6c@microchip.com> (raw)
In-Reply-To: <20220802121818.2201268-5-xianting.tian@linux.alibaba.com>

On 02/08/2022 13:18, Xianting Tian wrote:
> When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs()
> will be called to save regs to vmcore, we found "epc" value 00ffffffa5537400
> is not a valid kernel virtual address, but is a user virtual address. Other
> regs(eg, ra, sp, gp...) are correct kernel virtual address.
> Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which
> is saved in the task's stack.
> 
> [   21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45
> [   21.201979] Hardware name: riscv-virtio,qemu (DT)
> [   21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90
> [   21.202435]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c
> [   21.202707]  t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0
> [   21.202973]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
> [   21.203243]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00
> [   21.203519]  a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8
> [   21.203794]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
> [   21.204062]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
> [   21.204331]  s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700
> [   21.204606]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
> [   21.204876]  t5 : ff60000001218000 t6 : ff200000103338b8
> [   21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
> 
> With the incorrect PC, the backtrace showed by crash tool as below, the first
> stack frame is abnormal,
> 
> crash> bt
> PID: 113      TASK: ff60000002269600  CPU: 0    COMMAND: "sh"
>  #0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal
>  #1 [ff2000001039bcf0] panic at ffffffff806578ba
>  #2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030
>  #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8
>  #4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8
>  #5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc
>  #6 [ff2000001039be40] vfs_write at ffffffff80152ba6
>  #7 [ff2000001039be80] ksys_write at ffffffff80152ece
>  #8 [ff2000001039bed0] sys_write at ffffffff80152f46
> 
> With the patch, we can get current kernel mode PC, the output as below,
> 
> [   17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42
> [   17.607937] Hardware name: riscv-virtio,qemu (DT)
> [   17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90
> [   17.608441]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68
> [   17.608741]  t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0
> [   17.609025]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
> [   17.609320]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000
> [   17.609601]  a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4
> [   17.609894]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
> [   17.610186]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
> [   17.610469]  s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700
> [   17.610755]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
> [   17.611041]  t5 : ff60000001218000 t6 : ff20000010333988
> [   17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
> 
> With the correct PC, the backtrace showed by crash tool as below,
> 
> crash> bt
> PID: 113      TASK: ff6000000226c200  CPU: 0    COMMAND: "sh"
>  #0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal
>  #1 [ff20000010333cf0] panic at ffffffff806578c6
>  #2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
>  #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
>  #4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
>  #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
>  #6 [ff20000010333e40] vfs_write at ffffffff80152bb2
>  #7 [ff20000010333e80] ksys_write at ffffffff80152eda
>  #8 [ff20000010333ed0] sys_write at ffffffff80152f52
> 
> Fixes: e53d28180d4d ("RISC-V: Add kdump support")

This patch is also a fix, but not at the start of the series which
(I think) makes it less likely to be picked up for an auto-backport.

As it doesn't seem to depend on the prior patches, can you move this
up to 2/6 in the series?

> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/crash_save_regs.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/kernel/crash_save_regs.S b/arch/riscv/kernel/crash_save_regs.S
> index 7832fb763aba..b2a1908c0463 100644
> --- a/arch/riscv/kernel/crash_save_regs.S
> +++ b/arch/riscv/kernel/crash_save_regs.S
> @@ -44,7 +44,7 @@ SYM_CODE_START(riscv_crash_save_regs)
>  	REG_S t6,  PT_T6(a0)	/* x31 */
>  
>  	csrr t1, CSR_STATUS
> -	csrr t2, CSR_EPC
> +	auipc t2, 0x0
>  	csrr t3, CSR_TVAL
>  	csrr t4, CSR_CAUSE
>  
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com>
To: <xianting.tian@linux.alibaba.com>, <paul.walmsley@sifive.com>,
	<palmer@dabbelt.com>, <aou@eecs.berkeley.edu>,
	<anup@brainfault.org>, <heiko@sntech.de>, <guoren@kernel.org>,
	<mick@ics.forth.gr>, <alexandre.ghiti@canonical.com>,
	<bhe@redhat.com>, <vgoyal@redhat.com>, <dyoung@redhat.com>,
	<corbet@lwn.net>, <Conor.Dooley@microchip.com>
Cc: <kexec@lists.infradead.org>, <linux-doc@vger.kernel.org>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<crash-utility@redhat.com>, <huanyi.xj@alibaba-inc.com>,
	<heinrich.schuchardt@canonical.com>, <k-hagio-ab@nec.com>,
	<hschauhan@nulltrace.org>, <yixun.lan@gmail.com>
Subject: Re: [PATCH V5 4/6] RISC-V: Fixup getting correct current pc
Date: Tue, 9 Aug 2022 21:13:05 +0000	[thread overview]
Message-ID: <3fbfaa49-8ee9-a65c-133b-d0f072f0eb6c@microchip.com> (raw)
In-Reply-To: <20220802121818.2201268-5-xianting.tian@linux.alibaba.com>

On 02/08/2022 13:18, Xianting Tian wrote:
> When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs()
> will be called to save regs to vmcore, we found "epc" value 00ffffffa5537400
> is not a valid kernel virtual address, but is a user virtual address. Other
> regs(eg, ra, sp, gp...) are correct kernel virtual address.
> Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which
> is saved in the task's stack.
> 
> [   21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45
> [   21.201979] Hardware name: riscv-virtio,qemu (DT)
> [   21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90
> [   21.202435]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c
> [   21.202707]  t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0
> [   21.202973]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
> [   21.203243]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00
> [   21.203519]  a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8
> [   21.203794]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
> [   21.204062]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
> [   21.204331]  s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700
> [   21.204606]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
> [   21.204876]  t5 : ff60000001218000 t6 : ff200000103338b8
> [   21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
> 
> With the incorrect PC, the backtrace showed by crash tool as below, the first
> stack frame is abnormal,
> 
> crash> bt
> PID: 113      TASK: ff60000002269600  CPU: 0    COMMAND: "sh"
>  #0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal
>  #1 [ff2000001039bcf0] panic at ffffffff806578ba
>  #2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030
>  #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8
>  #4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8
>  #5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc
>  #6 [ff2000001039be40] vfs_write at ffffffff80152ba6
>  #7 [ff2000001039be80] ksys_write at ffffffff80152ece
>  #8 [ff2000001039bed0] sys_write at ffffffff80152f46
> 
> With the patch, we can get current kernel mode PC, the output as below,
> 
> [   17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42
> [   17.607937] Hardware name: riscv-virtio,qemu (DT)
> [   17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90
> [   17.608441]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68
> [   17.608741]  t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0
> [   17.609025]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
> [   17.609320]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000
> [   17.609601]  a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4
> [   17.609894]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
> [   17.610186]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
> [   17.610469]  s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700
> [   17.610755]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
> [   17.611041]  t5 : ff60000001218000 t6 : ff20000010333988
> [   17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
> 
> With the correct PC, the backtrace showed by crash tool as below,
> 
> crash> bt
> PID: 113      TASK: ff6000000226c200  CPU: 0    COMMAND: "sh"
>  #0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal
>  #1 [ff20000010333cf0] panic at ffffffff806578c6
>  #2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
>  #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
>  #4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
>  #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
>  #6 [ff20000010333e40] vfs_write at ffffffff80152bb2
>  #7 [ff20000010333e80] ksys_write at ffffffff80152eda
>  #8 [ff20000010333ed0] sys_write at ffffffff80152f52
> 
> Fixes: e53d28180d4d ("RISC-V: Add kdump support")

This patch is also a fix, but not at the start of the series which
(I think) makes it less likely to be picked up for an auto-backport.

As it doesn't seem to depend on the prior patches, can you move this
up to 2/6 in the series?

> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/crash_save_regs.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/kernel/crash_save_regs.S b/arch/riscv/kernel/crash_save_regs.S
> index 7832fb763aba..b2a1908c0463 100644
> --- a/arch/riscv/kernel/crash_save_regs.S
> +++ b/arch/riscv/kernel/crash_save_regs.S
> @@ -44,7 +44,7 @@ SYM_CODE_START(riscv_crash_save_regs)
>  	REG_S t6,  PT_T6(a0)	/* x31 */
>  
>  	csrr t1, CSR_STATUS
> -	csrr t2, CSR_EPC
> +	auipc t2, 0x0
>  	csrr t3, CSR_TVAL
>  	csrr t4, CSR_CAUSE
>  

WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com>
To: <xianting.tian@linux.alibaba.com>, <paul.walmsley@sifive.com>,
	<palmer@dabbelt.com>, <aou@eecs.berkeley.edu>,
	<anup@brainfault.org>, <heiko@sntech.de>, <guoren@kernel.org>,
	<mick@ics.forth.gr>, <alexandre.ghiti@canonical.com>,
	<bhe@redhat.com>, <vgoyal@redhat.com>, <dyoung@redhat.com>,
	<corbet@lwn.net>, <Conor.Dooley@microchip.com>
Cc: <kexec@lists.infradead.org>, <linux-doc@vger.kernel.org>,
	<linux-riscv@lists.infradead.org>, <linux-kernel@vger.kernel.org>,
	<crash-utility@redhat.com>, <huanyi.xj@alibaba-inc.com>,
	<heinrich.schuchardt@canonical.com>, <k-hagio-ab@nec.com>,
	<hschauhan@nulltrace.org>, <yixun.lan@gmail.com>
Subject: Re: [PATCH V5 4/6] RISC-V: Fixup getting correct current pc
Date: Tue, 9 Aug 2022 21:13:05 +0000	[thread overview]
Message-ID: <3fbfaa49-8ee9-a65c-133b-d0f072f0eb6c@microchip.com> (raw)
In-Reply-To: <20220802121818.2201268-5-xianting.tian@linux.alibaba.com>

On 02/08/2022 13:18, Xianting Tian wrote:
> When use 'echo c > /proc/sysrq-trigger' to trigger kdump, riscv_crash_save_regs()
> will be called to save regs to vmcore, we found "epc" value 00ffffffa5537400
> is not a valid kernel virtual address, but is a user virtual address. Other
> regs(eg, ra, sp, gp...) are correct kernel virtual address.
> Actually 0x00ffffffb0dd9400 is the user mode PC of 'PID: 113 Comm: sh', which
> is saved in the task's stack.
> 
> [   21.201701] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #45
> [   21.201979] Hardware name: riscv-virtio,qemu (DT)
> [   21.202160] epc : 00ffffffa5537400 ra : ffffffff80088640 sp : ff20000010333b90
> [   21.202435]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be7c
> [   21.202707]  t1 : 0720072007200720 t2 : 30203a7375746174 s0 : ff20000010333cf0
> [   21.202973]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
> [   21.203243]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 28c8f0aeffea4e00
> [   21.203519]  a5 : 28c8f0aeffea4e00 a6 : 0000000000000009 a7 : ffffffff8035c9b8
> [   21.203794]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
> [   21.204062]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
> [   21.204331]  s8 : 00ffffffef451410 s9 : 0000000000000007 s10: 00aaaaaac0510700
> [   21.204606]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
> [   21.204876]  t5 : ff60000001218000 t6 : ff200000103338b8
> [   21.205079] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
> 
> With the incorrect PC, the backtrace showed by crash tool as below, the first
> stack frame is abnormal,
> 
> crash> bt
> PID: 113      TASK: ff60000002269600  CPU: 0    COMMAND: "sh"
>  #0 [ff2000001039bb90] __efistub_.Ldebug_info0 at 00ffffffa5537400 <-- Abnormal
>  #1 [ff2000001039bcf0] panic at ffffffff806578ba
>  #2 [ff2000001039bd50] sysrq_reset_seq_param_set at ffffffff8038c030
>  #3 [ff2000001039bda0] __handle_sysrq at ffffffff8038c5f8
>  #4 [ff2000001039be00] write_sysrq_trigger at ffffffff8038cad8
>  #5 [ff2000001039be20] proc_reg_write at ffffffff801b7edc
>  #6 [ff2000001039be40] vfs_write at ffffffff80152ba6
>  #7 [ff2000001039be80] ksys_write at ffffffff80152ece
>  #8 [ff2000001039bed0] sys_write at ffffffff80152f46
> 
> With the patch, we can get current kernel mode PC, the output as below,
> 
> [   17.607658] CPU: 0 PID: 113 Comm: sh Kdump: loaded Not tainted 5.18.9 #42
> [   17.607937] Hardware name: riscv-virtio,qemu (DT)
> [   17.608150] epc : ffffffff800078f8 ra : ffffffff8008862c sp : ff20000010333b90
> [   17.608441]  gp : ffffffff810dde38 tp : ff6000000226c200 t0 : ffffffff8032be68
> [   17.608741]  t1 : 0720072007200720 t2 : 666666666666663c s0 : ff20000010333cf0
> [   17.609025]  s1 : 0000000000000000 a0 : ff20000010333b98 a1 : 0000000000000001
> [   17.609320]  a2 : 0000000000000010 a3 : 0000000000000000 a4 : 0000000000000000
> [   17.609601]  a5 : ff60000001c78000 a6 : 000000000000003c a7 : ffffffff8035c9a4
> [   17.609894]  s2 : ffffffff810df0a8 s3 : ffffffff810df718 s4 : ff20000010333b98
> [   17.610186]  s5 : 0000000000000000 s6 : 0000000000000007 s7 : ffffffff80c4a468
> [   17.610469]  s8 : 00ffffffca281410 s9 : 0000000000000007 s10: 00aaaaaab5bb6700
> [   17.610755]  s11: 0000000000000001 t3 : ff60000001218f00 t4 : ff60000001218f00
> [   17.611041]  t5 : ff60000001218000 t6 : ff20000010333988
> [   17.611255] status: 0000000200000020 badaddr: 0000000000000000 cause: 0000000000000008
> 
> With the correct PC, the backtrace showed by crash tool as below,
> 
> crash> bt
> PID: 113      TASK: ff6000000226c200  CPU: 0    COMMAND: "sh"
>  #0 [ff20000010333b90] riscv_crash_save_regs at ffffffff800078f8 <--- Normal
>  #1 [ff20000010333cf0] panic at ffffffff806578c6
>  #2 [ff20000010333d50] sysrq_reset_seq_param_set at ffffffff8038c03c
>  #3 [ff20000010333da0] __handle_sysrq at ffffffff8038c604
>  #4 [ff20000010333e00] write_sysrq_trigger at ffffffff8038cae4
>  #5 [ff20000010333e20] proc_reg_write at ffffffff801b7ee8
>  #6 [ff20000010333e40] vfs_write at ffffffff80152bb2
>  #7 [ff20000010333e80] ksys_write at ffffffff80152eda
>  #8 [ff20000010333ed0] sys_write at ffffffff80152f52
> 
> Fixes: e53d28180d4d ("RISC-V: Add kdump support")

This patch is also a fix, but not at the start of the series which
(I think) makes it less likely to be picked up for an auto-backport.

As it doesn't seem to depend on the prior patches, can you move this
up to 2/6 in the series?

> Co-developed-by: Guo Ren <guoren@kernel.org>
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> ---
>  arch/riscv/kernel/crash_save_regs.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/riscv/kernel/crash_save_regs.S b/arch/riscv/kernel/crash_save_regs.S
> index 7832fb763aba..b2a1908c0463 100644
> --- a/arch/riscv/kernel/crash_save_regs.S
> +++ b/arch/riscv/kernel/crash_save_regs.S
> @@ -44,7 +44,7 @@ SYM_CODE_START(riscv_crash_save_regs)
>  	REG_S t6,  PT_T6(a0)	/* x31 */
>  
>  	csrr t1, CSR_STATUS
> -	csrr t2, CSR_EPC
> +	auipc t2, 0x0
>  	csrr t3, CSR_TVAL
>  	csrr t4, CSR_CAUSE
>  
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2022-08-09 21:13 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-02 12:18 [PATCH V5 0/6] RISC-V fixups to work with crash tool Xianting Tian
2022-08-02 12:18 ` Xianting Tian
2022-08-02 12:18 ` Xianting Tian
2022-08-02 12:18 ` [PATCH V5 1/6] RISC-V: use __smp_processor_id() instead of smp_processor_id() Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-09 21:10   ` Conor.Dooley
2022-08-09 21:10     ` Conor.Dooley
2022-08-09 21:10     ` Conor.Dooley
2022-08-02 12:18 ` [PATCH V5 2/6] RISC-V: Add arch_crash_save_vmcoreinfo support Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-02 12:18 ` [PATCH V5 3/6] riscv: Add modules to virtual kernel memory layout dump Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-02 12:18 ` [PATCH V5 4/6] RISC-V: Fixup getting correct current pc Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-09 21:13   ` Conor.Dooley [this message]
2022-08-09 21:13     ` Conor.Dooley
2022-08-09 21:13     ` Conor.Dooley
2022-08-09 21:14     ` Conor.Dooley
2022-08-09 21:14       ` Conor.Dooley
2022-08-09 21:14       ` Conor.Dooley
2022-08-02 12:18 ` [PATCH V5 5/6] riscv: crash_core: Export kernel vm layout, phys_ram_base Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-09 21:20   ` Conor.Dooley
2022-08-09 21:20     ` Conor.Dooley
2022-08-09 21:20     ` Conor.Dooley
2022-08-10 12:00     ` Xianting Tian
2022-08-10 12:00       ` Xianting Tian
2022-08-10 12:00       ` Xianting Tian
2022-08-11  3:06   ` Bagas Sanjaya
2022-08-11  3:06     ` Bagas Sanjaya
2022-08-11  3:06     ` Bagas Sanjaya
2022-08-11  3:37     ` Xianting Tian
2022-08-11  3:37       ` Xianting Tian
2022-08-11  3:37       ` Xianting Tian
2022-08-02 12:18 ` [PATCH V5 6/6] RISC-V: Fixup schedule out issue in machine_crash_shutdown() Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-02 12:18   ` Xianting Tian
2022-08-09 21:20   ` Conor.Dooley
2022-08-09 21:20     ` Conor.Dooley
2022-08-09 21:20     ` Conor.Dooley
2022-08-09  6:58 ` [PATCH V5 0/6] RISC-V fixups to work with crash tool Xianting Tian
2022-08-09  6:58   ` Xianting Tian
2022-08-09  6:58   ` Xianting Tian
2022-08-09 21:24   ` Conor.Dooley
2022-08-09 21:24     ` Conor.Dooley
2022-08-09 21:24     ` Conor.Dooley
2022-08-11  2:54     ` Xianting Tian
2022-08-11  2:54       ` Xianting Tian
2022-08-11  2:54       ` Xianting Tian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3fbfaa49-8ee9-a65c-133b-d0f072f0eb6c@microchip.com \
    --to=conor.dooley@microchip.com \
    --cc=alexandre.ghiti@canonical.com \
    --cc=anup@brainfault.org \
    --cc=aou@eecs.berkeley.edu \
    --cc=bhe@redhat.com \
    --cc=corbet@lwn.net \
    --cc=crash-utility@redhat.com \
    --cc=dyoung@redhat.com \
    --cc=guoren@kernel.org \
    --cc=heiko@sntech.de \
    --cc=heinrich.schuchardt@canonical.com \
    --cc=hschauhan@nulltrace.org \
    --cc=huanyi.xj@alibaba-inc.com \
    --cc=k-hagio-ab@nec.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=mick@ics.forth.gr \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=vgoyal@redhat.com \
    --cc=xianting.tian@linux.alibaba.com \
    --cc=yixun.lan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.