From: <Conor.Dooley@microchip.com>
To: <Conor.Dooley@microchip.com>, <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>
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:14:25 +0000 [thread overview]
Message-ID: <0e01c36a-bf06-6065-daee-b0cc78c79e4f@microchip.com> (raw)
In-Reply-To: <3fbfaa49-8ee9-a65c-133b-d0f072f0eb6c@microchip.com>
On 09/08/2022 22:13, Conor.Dooley@microchip.com wrote:
> 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?
>
Plus, it'd be nice if the subject gave some more sub component context
& the same applies to most of the patches in the series.
_______________________________________________
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: <Conor.Dooley@microchip.com>, <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>
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:14:25 +0000 [thread overview]
Message-ID: <0e01c36a-bf06-6065-daee-b0cc78c79e4f@microchip.com> (raw)
In-Reply-To: <3fbfaa49-8ee9-a65c-133b-d0f072f0eb6c@microchip.com>
On 09/08/2022 22:13, Conor.Dooley@microchip.com wrote:
> 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?
>
Plus, it'd be nice if the subject gave some more sub component context
& the same applies to most of the patches in the series.
WARNING: multiple messages have this Message-ID (diff)
From: <Conor.Dooley@microchip.com>
To: <Conor.Dooley@microchip.com>, <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>
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:14:25 +0000 [thread overview]
Message-ID: <0e01c36a-bf06-6065-daee-b0cc78c79e4f@microchip.com> (raw)
In-Reply-To: <3fbfaa49-8ee9-a65c-133b-d0f072f0eb6c@microchip.com>
On 09/08/2022 22:13, Conor.Dooley@microchip.com wrote:
> 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?
>
Plus, it'd be nice if the subject gave some more sub component context
& the same applies to most of the patches in the series.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2022-08-09 21:15 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
2022-08-09 21:13 ` Conor.Dooley
2022-08-09 21:13 ` Conor.Dooley
2022-08-09 21:14 ` Conor.Dooley [this message]
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=0e01c36a-bf06-6065-daee-b0cc78c79e4f@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.