ARM64 kexec/kdump timeline

Commit Message

Pratyush Anand June 1, 2015, 6:25 a.m. UTC

On Thursday 28 May 2015 04:44 AM, Timur Tabi wrote:
> On 05/27/2015 11:39 AM, Arnd Bergmann wrote:
>> ACPI support has just been merged and is still experimental. You
>> should be able to boot your system by passing a DT blob at the
>> initial boot that matches your hardware. Can you try if that
>> makes kexec work?
>
> If I had an initial DT blob that matched by hardware, I wouldn't need
> ACPI support!  This is an ARM64 Server system.  There is no device tree
> for the hardware.  Everything is in ACPI.

So what error do you see when you execute kexec.

We had seen a failure with check_cpu_nodes(), when booting with ACPI 
without any DTB.

If you see the similar failure, then can you pl try following:

          * Put the DTB after the kernel with an alignment of 128 KiB, 
giving

~Pratyush

Comments

Timur Tabi June 29, 2015, 11:20 p.m. UTC | #1

On Mon, Jun 1, 2015 at 1:25 AM, Pratyush Anand <[e-mail]> wrote:

> We had seen a failure with check_cpu_nodes(), when booting with ACPI without
> any DTB.
>
> If you see the similar failure, then can you pl try following:
>
> diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
> index 7b219097dfff..8e085212d8a5 100644
> --- a/kexec/arch/arm64/kexec-arm64.c
> +++ b/kexec/arch/arm64/kexec-arm64.c
> @@ -640,7 +640,7 @@ int arm64_load_other_segments(struct kexec_info *info,
>         result =  check_cpu_nodes(&dtb_1, &dtb_2);
>
>         if (result)
> -               return result;
> +               fprintf(stderr, "kexec: Warning: No device tree
> available.\n");
>
>         /*
>          * Put the DTB after the kernel with an alignment of 128 KiB, giving

I finally got around to testing this.  With this change, the tool just
displays the error message and continues working.  So +1 for this
patch.

It would be better, of course, if the tool could parse the ACPI tables
and generate a compatible device tree with CPU nodes.  Do you have any
plans to support ACPI with this tool?  We're working on that
internally, but it's mostly hacks and work-arounds for now.

Azriel Samson July 8, 2015, 11:03 p.m. UTC | #2

Hi,

When booting the crash kernel with ACPI, how do you ensure that the ACPI
tables fall within the kernel's memmap region?
I was able to boot with ACPI when the crash kernel's memory overlapped
with the ACPI tables(based on the "crashkernel" and "mem" boot arguments).

Is there a better way to make the ACPI tables available to the crash kernel?

> On Mon, Jun 1, 2015 at 1:25 AM, Pratyush Anand <[e-mail]> wrote:
>
>> We had seen a failure with check_cpu_nodes(), when booting with ACPI
>> without
>> any DTB.
>>
>> If you see the similar failure, then can you pl try following:
>>
>> diff --git a/kexec/arch/arm64/kexec-arm64.c
>> b/kexec/arch/arm64/kexec-arm64.c
>> index 7b219097dfff..8e085212d8a5 100644
>> --- a/kexec/arch/arm64/kexec-arm64.c
>> +++ b/kexec/arch/arm64/kexec-arm64.c
>> @@ -640,7 +640,7 @@ int arm64_load_other_segments(struct kexec_info
>> *info,
>>         result =  check_cpu_nodes(&dtb_1, &dtb_2);
>>
>>         if (result)
>> -               return result;
>> +               fprintf(stderr, "kexec: Warning: No device tree
>> available.\n");
>>
>>         /*
>>          * Put the DTB after the kernel with an alignment of 128 KiB,
>> giving
>
> I finally got around to testing this.  With this change, the tool just
> displays the error message and continues working.  So +1 for this
> patch.
>
> It would be better, of course, if the tool could parse the ACPI tables
> and generate a compatible device tree with CPU nodes.  Do you have any
> plans to support ACPI with this tool?  We're working on that
> internally, but it's mostly hacks and work-arounds for now.
>
> --
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project.
>

Azriel Samson Dec. 4, 2015, 9:53 p.m. UTC | #3

Hi,

On 7/13/2015 3:03 AM, AKASHI, Takahiro wrote:
> Sorry for not replying soon.
>
> On 9 July 2015 at 08:03, Azriel Samson <[e-mail]
> <mailto:[e-mail]>> wrote:
>  >
>  > Hi,
>  >
>  > When booting the crash kernel with ACPI, how do you ensure that the ACPI
>  > tables fall within the kernel's memmap region?
>  > I was able to boot with ACPI when the crash kernel's memory overlapped
>  > with the ACPI tables(based on the "crashkernel" and "mem" boot
> arguments).
>
> I don't think this is a right way to use kdump in ACPI environment on arm64
> because "mem" parameter only limits the maximum size of usable memory
> and so the crash dump data (/proc/vmcore) can get easily corrupted if
> the reserved
> memory region that the crash dump kernel can use also contains any
> portion of
> memory which belong to the crashed kernel.
>
> In the current implementation of arm64 kdump, kexec command manages to
>   exclude such memory regions by modifying the device tree passed on to
> the crash dump kernel.
>
>  > Is there a better way to make the ACPI tables available to the crash
> kernel?
>
> So ACPI tables is not the only problem.
> x86 seems to use "memmap" kernel parameter instead.(?)

I was able to test kdump with the following patch from Mark Salter which 
is needed for supporting ACPI tables that lie outside of kernel RAM:
https://git.fedorahosted.org/cgit/kernel-arm64.git/commit/?h=devel&id=a75bcec5679a2ff82f23c5cc335c77da158a6dc5


>
> Thanks,
> -Takahiro AKASHI
>

Patch

diff --git a/kexec/arch/arm64/kexec-arm64.c b/kexec/arch/arm64/kexec-arm64.c
index 7b219097dfff..8e085212d8a5 100644
--- a/kexec/arch/arm64/kexec-arm64.c
+++ b/kexec/arch/arm64/kexec-arm64.c
@@ -640,7 +640,7 @@  int arm64_load_other_segments(struct kexec_info *info,
         result =  check_cpu_nodes(&dtb_1, &dtb_2);

         if (result)
-               return result;
+               fprintf(stderr, "kexec: Warning: No device tree 
available.\n");

         /*