Hi Akashi,
On Thursday 26 March 2015 01:58 PM, AKASHI Takahiro wrote:
> This patch set enables kdump (crash dump kernel) support on arm64 on top of
> Geoff's kexec patchset.
>
> In this version, there are some arm64-specific usage/constraints:
> 1) "mem=" boot parameter must be specified on crash dump kernel
> 2) Kvm will not be enabled on crash dump kernel even if configured
> See commit messages and Documentation/kdump/kdump.txt for details.
>
> The only concern I have is whether or not we can use the exact same kernel
> as both system kernel and crash dump kernel. The current arm64 kernel is
> not relocatable in the exact sense but I have no problems in using the same
> binary for testing kdump.
>
> I tested the code with
> - ATF v1.1 + EDK2(UEFI) v3.0-rc0
> - kernel v4.0-rc4 + Geoff' kexec v8
> on Base fast model, using my yet-to-be-submitted kexec-tools [1].
> You may want to start a kernel with the following boot parameter:
> crashkernel=64M@2240M
> and try
> $ kexec -p --load <vmlinux> --append ...
> $ echo c > /proc/sysrq-trigger
>
I tried to use your kdump patches for kernel and kexec-tools. I am not
able to load the crash kernel properly.
I passed crashkernel=64M@259G (My 8GB RAM starts at 256G) to primary kernel.
Used following to load the crash kernel
kexec -p --load vmlinux --append="$( cat /proc/cmdline ) maxcpus=1
mem=64M reset_devices"
I see:
kexec_load failed: Cannot assign requested address
entry = 0x40c40005d0 flags = 0xb70001
What I noticed that arm64_load_other_segments does not calculate correct
load address for purgatory or if I pass initrd then for that too within
crash kernel allocated memory.
Shouldn't we have a function similar to locate_dtb_in_crashmem for
putgatory as well as initrd? I can try to fix this allocation, but I was
just wondering if I understood correctly or I am missing something.
~Pratyush
> To examine vmcore (/proc/vmcore), you may use
> - gdb v7.7 or later
> - crash + a small patch (to recognize v4.0 kernel)
>
> [1] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git
>
>
> AKASHI Takahiro (5):
> arm64: kdump: reserve memory for crash dump kernel
> arm64: kdump: implement machine_crash_shutdown()
> arm64: kdump: do not go into EL2 before starting a crash dump kernel
> arm64: add kdump support
> arm64: enable kdump in the arm64 defconfig
>
> Documentation/kdump/kdump.txt | 31 ++++++++++++++-
> arch/arm64/Kconfig | 12 ++++++
> arch/arm64/configs/defconfig | 1 +
> arch/arm64/include/asm/kexec.h | 34 +++++++++++++++-
> arch/arm64/kernel/Makefile | 1 +
> arch/arm64/kernel/crash_dump.c | 71 +++++++++++++++++++++++++++++++++
> arch/arm64/kernel/machine_kexec.c | 55 +++++++++++++++++++++++++-
> arch/arm64/kernel/process.c | 7 +++-
> arch/arm64/kernel/setup.c | 78 +++++++++++++++++++++++++++++++++++++
> arch/arm64/kernel/smp.c | 10 ++++-
> 10 files changed, 294 insertions(+), 6 deletions(-)
> create mode 100644 arch/arm64/kernel/crash_dump.c
>
Hi Pratyush,
On 04/02/2015 12:56 AM, Pratyush Anand wrote:
> Hi Akashi,
>
> On Thursday 26 March 2015 01:58 PM, AKASHI Takahiro wrote:
>> This patch set enables kdump (crash dump kernel) support on arm64 on top of
>> Geoff's kexec patchset.
>>
>> In this version, there are some arm64-specific usage/constraints:
>> 1) "mem=" boot parameter must be specified on crash dump kernel
>> 2) Kvm will not be enabled on crash dump kernel even if configured
>> See commit messages and Documentation/kdump/kdump.txt for details.
>>
>> The only concern I have is whether or not we can use the exact same kernel
>> as both system kernel and crash dump kernel. The current arm64 kernel is
>> not relocatable in the exact sense but I have no problems in using the same
>> binary for testing kdump.
>>
>> I tested the code with
>> - ATF v1.1 + EDK2(UEFI) v3.0-rc0
>> - kernel v4.0-rc4 + Geoff' kexec v8
>> on Base fast model, using my yet-to-be-submitted kexec-tools [1].
>> You may want to start a kernel with the following boot parameter:
>> crashkernel=64M@2240M
>> and try
>> $ kexec -p --load <vmlinux> --append ...
>> $ echo c > /proc/sysrq-trigger
>>
>
> I tried to use your kdump patches for kernel and kexec-tools. I am not able to load the crash kernel properly.
>
>
> I passed crashkernel=64M@259G (My 8GB RAM starts at 256G) to primary kernel.
>
> Used following to load the crash kernel
> kexec -p --load vmlinux --append="$( cat /proc/cmdline ) maxcpus=1 mem=64M reset_devices"
>
> I see:
>
> kexec_load failed: Cannot assign requested address
> entry = 0x40c40005d0 flags = 0xb70001
>
> What I noticed that arm64_load_other_segments does not calculate correct load address for purgatory or if I pass initrd
> then for that too within crash kernel allocated memory.
It seems that you hit the same problem that I mentioned in:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/334613.html
Please try my latest kexec-tools in my linaro repo (branch name is kdump/v0.11)
and let me know the result.
> Shouldn't we have a function similar to locate_dtb_in_crashmem for putgatory as well as initrd? I can try to fix this
> allocation, but I was just wondering if I understood correctly or I am missing something.
I don't think a function for purgatory is necessary since we try to find a hole
just after dtb.
Thanks,
-Takahiro AKASHI
> ~Pratyush
>
>
>> To examine vmcore (/proc/vmcore), you may use
>> - gdb v7.7 or later
>> - crash + a small patch (to recognize v4.0 kernel)
>>
>> [1] https://git.linaro.org/people/takahiro.akashi/kexec-tools.git
>>
>>
>> AKASHI Takahiro (5):
>> arm64: kdump: reserve memory for crash dump kernel
>> arm64: kdump: implement machine_crash_shutdown()
>> arm64: kdump: do not go into EL2 before starting a crash dump kernel
>> arm64: add kdump support
>> arm64: enable kdump in the arm64 defconfig
>>
>> Documentation/kdump/kdump.txt | 31 ++++++++++++++-
>> arch/arm64/Kconfig | 12 ++++++
>> arch/arm64/configs/defconfig | 1 +
>> arch/arm64/include/asm/kexec.h | 34 +++++++++++++++-
>> arch/arm64/kernel/Makefile | 1 +
>> arch/arm64/kernel/crash_dump.c | 71 +++++++++++++++++++++++++++++++++
>> arch/arm64/kernel/machine_kexec.c | 55 +++++++++++++++++++++++++-
>> arch/arm64/kernel/process.c | 7 +++-
>> arch/arm64/kernel/setup.c | 78 +++++++++++++++++++++++++++++++++++++
>> arch/arm64/kernel/smp.c | 10 ++++-
>> 10 files changed, 294 insertions(+), 6 deletions(-)
>> create mode 100644 arch/arm64/kernel/crash_dump.c
>>
On Thursday 02 April 2015 04:57 AM, AKASHI Takahiro wrote:
> Please try my latest kexec-tools in my linaro repo (branch name is
> kdump/v0.11)
> and let me know the result.
Thanks a lot.. Just fetched your repo and found v.0.11.
With this crash kernel loaded successfully, if I do not use initrd.
With following I still see Overlapping memory segments
kexec -p /home/panand/work/kernel/bsa2_kdump/vmlinux
--initrd=/boot/initramfs-3.19.0.bz1198945+.img --append="$( cat
/proc/cmdline ) maxcpus=1 mem=64M reset_devices"
~Pratyush
Pratyush,
On 04/02/2015 01:58 PM, Pratyush Anand wrote:
>
>
> On Thursday 02 April 2015 04:57 AM, AKASHI Takahiro wrote:
>> Please try my latest kexec-tools in my linaro repo (branch name is
>> kdump/v0.11)
>> and let me know the result.
>
> Thanks a lot.. Just fetched your repo and found v.0.11.
>
> With this crash kernel loaded successfully, if I do not use initrd.
>
> With following I still see Overlapping memory segments
>
> kexec -p /home/panand/work/kernel/bsa2_kdump/vmlinux --initrd=/boot/initramfs-3.19.0.bz1198945+.img --append="$( cat
> /proc/cmdline ) maxcpus=1 mem=64M reset_devices"
How big is your initrd?
If it is good small, please tell me segments info, or messages from add_segment_phys_virt()
for all the segments.
FYI,
my latest kexec-tools, ie. v0.11, automatically appends "mem=".
Thanks,
-Takahiro AKASHI
> ~Pratyush
On Thursday 02 April 2015 11:07 AM, AKASHI Takahiro wrote:
> Pratyush,
>
> On 04/02/2015 01:58 PM, Pratyush Anand wrote:
>>
>>
>> On Thursday 02 April 2015 04:57 AM, AKASHI Takahiro wrote:
>>> Please try my latest kexec-tools in my linaro repo (branch name is
>>> kdump/v0.11)
>>> and let me know the result.
>>
>> Thanks a lot.. Just fetched your repo and found v.0.11.
>>
>> With this crash kernel loaded successfully, if I do not use initrd.
>>
>> With following I still see Overlapping memory segments
>>
>> kexec -p /home/panand/work/kernel/bsa2_kdump/vmlinux
>> --initrd=/boot/initramfs-3.19.0.bz1198945+.img --append="$( cat
>> /proc/cmdline ) maxcpus=1 mem=64M reset_devices"
>
> How big is your initrd?
> If it is good small, please tell me segments info, or messages from
> add_segment_phys_virt()
> for all the segments.
>
add_segment_phys_virt: 000000000dcd0b90 - 000000000dcd0f90 (00000400) ->
00000040c3ff0000 - 00000040c4000000 (00010000)
add_segment_phys_virt: 000003ff88c10010 - 000003ff8984a010 (00c3a000) ->
00000040c0080000 - 00000040c1310000 (01290000)
add_segment_phys_virt: 000000000dcd53c0 - 000000000dcd96b8 (000042f8) ->
00000040c0000000 - 00000040c0010000 (00010000)
add_segment_phys_virt: 000003ff87360010 - 000003ff88bfcc2f (0189cc1f) ->
00000040c0010000 - 00000040c18b0000 (018a0000)
Overlapping memory segments at 0x40c18b0000
sort_segments failed
Why do we try to fit dtb just after crash_reserved_mem.start. Should n't
it should start after crash_reserved_mem.start + arm64_mem.text_offset +
arm64_mem.image_size
I tried following and it works perfectly:
diff --git a/kexec/arch/arm64/crashdump-arm64.c
b/kexec/arch/arm64/crashdump-arm64.c
index 41266f294589..75f4e4d269ca 100644
--- a/kexec/arch/arm64/crashdump-arm64.c
+++ b/kexec/arch/arm64/crashdump-arm64.c
@@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct
kexec_info *info)
off_t locate_dtb_in_crashmem(struct kexec_info *info, off_t dtb_size)
{
return locate_hole(info, dtb_size, 128UL * 1024,
- crash_reserved_mem.start, crash_reserved_mem.end, 1);
+ crash_reserved_mem.start + arm64_mem.text_offset +
+ arm64_mem.image_size, crash_reserved_mem.end, 1);
}
With this changes new allocations are:
add_segment_phys_virt: 0000000010350b90 - 0000000010350f90 (00000400) ->
00000040c3ff0000 - 00000040c4000000 (00010000)
add_segment_phys_virt: 000003ff7ad70010 - 000003ff7b9aa010 (00c3a000) ->
00000040c0080000 - 00000040c1310000 (01290000)
add_segment_phys_virt: 00000000103553c0 - 00000000103596b8 (000042f8) ->
00000040c1360000 - 00000040c1370000 (00010000)
add_segment_phys_virt: 000003ff794c0010 - 000003ff7ad5cc2f (0189cc1f) ->
00000040c1370000 - 00000040c2c10000 (018a0000)
add_segment_phys_virt: 00000000103596c0 - 0000000010360190 (00006ad0) ->
00000040c2c10000 - 00000040c2c20000 (00010000)
Crash kernel loaded upon panic.
~Pratyush
On 04/02/2015 03:01 PM, Pratyush Anand wrote:
>
>
> On Thursday 02 April 2015 11:07 AM, AKASHI Takahiro wrote:
>> Pratyush,
>>
>> On 04/02/2015 01:58 PM, Pratyush Anand wrote:
>>>
>>>
>>> On Thursday 02 April 2015 04:57 AM, AKASHI Takahiro wrote:
>>>> Please try my latest kexec-tools in my linaro repo (branch name is
>>>> kdump/v0.11)
>>>> and let me know the result.
>>>
>>> Thanks a lot.. Just fetched your repo and found v.0.11.
>>>
>>> With this crash kernel loaded successfully, if I do not use initrd.
>>>
>>> With following I still see Overlapping memory segments
>>>
>>> kexec -p /home/panand/work/kernel/bsa2_kdump/vmlinux
>>> --initrd=/boot/initramfs-3.19.0.bz1198945+.img --append="$( cat
>>> /proc/cmdline ) maxcpus=1 mem=64M reset_devices"
>>
>> How big is your initrd?
>> If it is good small, please tell me segments info, or messages from
>> add_segment_phys_virt()
>> for all the segments.
>>
>
> add_segment_phys_virt: 000000000dcd0b90 - 000000000dcd0f90 (00000400) -> 00000040c3ff0000 - 00000040c4000000 (00010000)
> add_segment_phys_virt: 000003ff88c10010 - 000003ff8984a010 (00c3a000) -> 00000040c0080000 - 00000040c1310000 (01290000)
> add_segment_phys_virt: 000000000dcd53c0 - 000000000dcd96b8 (000042f8) -> 00000040c0000000 - 00000040c0010000 (00010000)
> add_segment_phys_virt: 000003ff87360010 - 000003ff88bfcc2f (0189cc1f) -> 00000040c0010000 - 00000040c18b0000 (018a0000)
> Overlapping memory segments at 0x40c18b0000
> sort_segments failed
>
> Why do we try to fit dtb just after crash_reserved_mem.start. Should n't it should start after crash_reserved_mem.start
> + arm64_mem.text_offset + arm64_mem.image_size
Yeah, worth considering :)
-Takahiro AKASHI
>
> I tried following and it works perfectly:
>
> diff --git a/kexec/arch/arm64/crashdump-arm64.c b/kexec/arch/arm64/crashdump-arm64.c
> index 41266f294589..75f4e4d269ca 100644
> --- a/kexec/arch/arm64/crashdump-arm64.c
> +++ b/kexec/arch/arm64/crashdump-arm64.c
> @@ -312,5 +312,6 @@ void set_crash_entry(struct mem_ehdr *ehdr, struct kexec_info *info)
> off_t locate_dtb_in_crashmem(struct kexec_info *info, off_t dtb_size)
> {
> return locate_hole(info, dtb_size, 128UL * 1024,
> - crash_reserved_mem.start, crash_reserved_mem.end, 1);
> + crash_reserved_mem.start + arm64_mem.text_offset +
> + arm64_mem.image_size, crash_reserved_mem.end, 1);
> }
>
> With this changes new allocations are:
> add_segment_phys_virt: 0000000010350b90 - 0000000010350f90 (00000400) -> 00000040c3ff0000 - 00000040c4000000 (00010000)
> add_segment_phys_virt: 000003ff7ad70010 - 000003ff7b9aa010 (00c3a000) -> 00000040c0080000 - 00000040c1310000 (01290000)
> add_segment_phys_virt: 00000000103553c0 - 00000000103596b8 (000042f8) -> 00000040c1360000 - 00000040c1370000 (00010000)
> add_segment_phys_virt: 000003ff794c0010 - 000003ff7ad5cc2f (0189cc1f) -> 00000040c1370000 - 00000040c2c10000 (018a0000)
> add_segment_phys_virt: 00000000103596c0 - 0000000010360190 (00006ad0) -> 00000040c2c10000 - 00000040c2c20000 (00010000)
>
>
> Crash kernel loaded upon panic.
>
> ~Pratyush