ARM64 kexec/kdump timeline

I feel kexec was ready to merge nine months ago. Users have only sent private e-mails like yourself, so there has been no public inquiries, and so, the arm64 maintainers think kexec is not of interest to users.

Quoted 4 lines · Geoff Levand

I feel kexec was ready to merge nine months ago. Users have only sent private e-mails like yourself, so there has been no public inquiries, and so, the arm64 maintainers think kexec is not of interest to users.

Does kexec on ARM64 support ACPI? In some of our initial tests, it appears that the kexec'd kernel won't boot because it's expecting a device tree, and we don't have one.

ARM64 servers are supposed to use ACPI instead of a device tree.

Quoted 7 lines · Timur Tabi

Quoted 4 lines · Geoff Levand

I feel kexec was ready to merge nine months ago. Users have only sent private e-mails like yourself, so there has been no public inquiries, and so, the arm64 maintainers think kexec is not of interest to users.

Quoted 6 lines

Does kexec on ARM64 support ACPI? In some of our initial tests, it appears that the kexec'd kernel won't boot because it's expecting a device tree, and we don't have one.

ARM64 servers are supposed to use ACPI instead of a device tree.

The latest arm64 kexec patches support booting via UEFI, and when booting via UEFI, the ACPI root pointer is retrieved from a UEFI configuration table if the FDT contains no system description. So ACPI support should not depend at all on how kexec is implemented (unless your FDT does contain a system description, in which case you should pass along the 'acpi=xxx' param that was given to the cold booted kernel)

Timur, can you provide more detailed information then we can debug into it?

Does kexec on ARM64 support ACPI? In some of our initial tests, it appears that the kexec'd kernel won't boot because it's expecting a device tree, and we don't have one.

Quoted 3 lines · Geoff Levand

I feel kexec was ready to merge nine months ago. Users have only sent private e-mails like yourself, so there has been no public inquiries, and so, the arm64 maintainers think kexec is not of interest to users.

Does kexec on ARM64 support ACPI? In some of our initial tests, it appears that the kexec'd kernel won't boot because it's expecting a device tree, and we don't have one.

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?

Quoted 4 lines · Arnd Bergmann

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.

What does x86 do? They don't have device trees, but they do use ACPI, so how does kexec work there?

Quoted 9 lines · Timur Tabi

Quoted 5 lines · Arnd Bergmann

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?

Quoted 6 lines

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.

What does x86 do? They don't have device trees, but they do use ACPI, so how does kexec work there?

So the key point is that we need to get the root pointer to the ACPI tables (RSDP), which is in the UEFI configuration table as Ard said, I think this part is the same for ARM64 and x86.

ACPI provide an early param "acpi_rsdp" for kexec use as a option, you can refer to Documentation/kernel-parameters.txt.

Quoted 4 lines · Arnd Bergmann

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.

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:

kexec/arch/arm64/kexec-arm64.c +1 -1

index 7b219097dfff..8e085212d8a5 100644
@@ -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

Quoted 21 lines

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:

kexec/arch/arm64/kexec-arm64.c +1 -1

index 7b219097dfff..8e085212d8a5 100644
@@ -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");
 

Quoted 3 lines

/*
* 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.

Sorry for not replying soon.

Quoted 7 lines · On 9 July 2015 at 08:03, Azriel Samson <[email protected]…

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.

Quoted 1 line

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.(?)

Thanks,
-Takahiro AKASHI