sorry forget to cc.
-------- Original message --------
Theme: Re: [PATCH] ARM: Add arm description to Documentation/kdump/kdump.txt
On: Tue, 05 Aug 2014 09:55:30 +0800
From: Hu Keping <hukeping@xxxxxxxxxx>
To: vgoyal at redhat.com
Cc: sdu.liu at huawei.com, peifeiyue at huawei.com
on 2014/7/31 20:39, Vivek Goyal wrote:
> On Thu, Jul 31, 2014 at 02:03:31PM +0800, HuKeping wrote:
>> Add arm specific parts to kdump kernel documentation.
>>
>
> Hi Hu,
>
> So kexec on arm (32bit) now works? All the kernel pieces and kexec-tools
> pieces are upstream? (Sorry, I have not been able to keeptrack of arm
> development).
>
>
Yes,I run the routine on vexpress(v2p-ca9) with Cortex-A9 MPCore and it
works fine
>> ----------------------------------------
>> Signed-off-by: Hu Keping <hukeping at huawei.com>
>> ---
>> Documentation/kdump/kdump.txt | 25 ++++++++++++++++++++++---
>> 1 file changed, 22 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
>> index 88d5a86..5fc98d6 100644
>> --- a/Documentation/kdump/kdump.txt
>> +++ b/Documentation/kdump/kdump.txt
>> @@ -18,7 +18,7 @@ memory image to a dump file on the local disk, or across the network to
>> a remote system.
>>
>> Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
>> -and s390x architectures.
>> +s390x and arm architectures.
>>
>> When the system kernel boots, it reserves a small section of memory for
>> the dump-capture kernel. This ensures that ongoing Direct Memory Access
>> @@ -112,7 +112,7 @@ There are two possible methods of using Kdump.
>> 2) Or use the system kernel binary itself as dump-capture kernel and there is
>> no need to build a separate dump-capture kernel. This is possible
>> only with the architectures which support a relocatable kernel. As
>> - of today, i386, x86_64, ppc64 and ia64 architectures support relocatable
>> + of today, i386, x86_64, ppc64, ia64 and arm architectures support relocatable
>> kernel.
>
> So zImage is relocatable on arm?
>
Yes, only if the CONFIG_AUTO_ZRELADDR selected.
>>
>> Building a relocatable kernel is advantageous from the point of view that
>> @@ -296,6 +296,12 @@ Boot into System Kernel
>> on the memory consumption of the kdump system. In general this is not
>> dependent on the memory size of the production system.
>>
>> + On arm, use "crashkernel=Y at X".
>
> Do you support other forms of crashkernel= parameter? Like crashkernel=X.
> A longer list of parameters is available in kernel-parameters.txt.
>
Assume [0x60000000-0x7fffffff] : System RAM
The forms of, for example crashkernel=128M at 1792M and
crashkernel=128M at 0x70000000 are both OK.
But there will be a panic if use crashkernel=Y or crashkernal=YM at Z where
Z is NOT in the System RAM range.
The extended crashkernel syntax is okay, but again, "@offset" is
required. Like:
crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
range=start-[end]
different with the old
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=start-[end]
>> Note that the start address of the kernel
>> + will be aligned to 128MiB (0x08000000),
>
> x86 kernel is 2MB aligned. 128MB aligned seems to be huge. Where does
> that restriction come from.
>
ZRELADDR is the physical address where the decompressed kernel
image(from zImage) will be placed, If AUTO_ZRELADDR is selected, the
address will be determined at run-time by masking the current IP with
0xf8000000.
One can refers to LINUX/arch/arm/boot/compressed/head.S
168 #ifdef CONFIG_AUTO_ZRELADDR
169 @ determine final kernel image address
170 mov r4, pc
171 and r4, r4, #0xf8000000
172 add r4, r4, #TEXT_OFFSET
173 #else
174 ldr r4, =zreladdr
175 #endif
>> so if the start address is not then
>> + any space blow the alignment point may be overwrited by the dump-caputre kernel,
>> + which means it is possible that the vmcore is not that precise as expected.
>
> What does above statement mean? I think it requires some work. And also
> some examples of what's a reasonable crashkernel=X at Y values for arm.
>
>
As the statement above, one can also set the parameter like
crashkernel=128M at 0x69000000, but it will be reset to 128M at 0x68000000.
Then what will happen to 0x68000000-0x68ffffff is UNPREDICTABLE.
Same with using the extended crashkernel syntax.
>> +
>> +
>> Load the Dump-capture Kernel
>> ============================
>>
>> @@ -315,7 +321,8 @@ For ia64:
>> - Use vmlinux or vmlinuz.gz
>> For s390x:
>> - Use image or bzImage
>> -
>> +For arm:
>> + - Use zImage
>>
>> If you are using a uncompressed vmlinux image then use following command
>> to load dump-capture kernel.
>> @@ -331,6 +338,15 @@ to load dump-capture kernel.
>> --initrd=<initrd-for-dump-capture-kernel> \
>> --append="root=<root-dev> <arch-specific-options>"
>>
>> +If you are using a compressed zImage, then use following command
>> +to load dump-capture kernel.
>> +
>> + kexec --type zImage -p <dump-capture-kernel-bzImage> \
>> + --initrd=<initrd-for-dump-capture-kernel> \
>> + --dtb=<dtb-for-dump-capture-kernel> \
>> + --append="root=<root-dev> <arch-specific-options>"
>> +
>> +
>> Please note, that --args-linux does not need to be specified for ia64.
>> It is planned to make this a no-op on that architecture, but for now
>> it should be omitted
>> @@ -347,6 +363,9 @@ For ppc64:
>> For s390x:
>> "1 maxcpus=1 cgroup_disable=memory"
>>
>> +For arm:
>> + "1 maxcpus=1 reset_devices"
>> +
>
> nr_cpus=1 does not work on arm? We prefer that over maxcpus=1.
>
It does works, but I think there is a little bug with using nr_cpus.
There will be a warning when dump-caputre kernel booting if use nr_cpus:
"[ 0.000000] DT/cpu 2nodes greater than max cores 1, capping them"
This is from arch/arm/kernel/devtree.c, in function
void __init arm_dt_init_cpu_maps(void)
145 if (WARN(cpuidx > nr_cpu_ids, "DT /cpu %u nodes greater than "
146 "max cores %u, capping them\n",
147 cpuidx, nr_cpu_ids)) {
148 cpuidx = nr_cpu_ids;
149 break;
150 }
Since we have already using nr_cpus to specify the number of cpus we
want to be online, kdump should not to make the comparison with dtb
(which is strongly recommended on arm-32bit ) again, but it does, so the
warning out.
Meanwhile the maxcpus works fine.
> Thanks
> Vivek
>
> .
>
Sincerely yours,
Hu Keping
