[PATCH] ARM: Add arm description to Documentation/kdump/kdump.txt
vgoyal at redhat.com
Thu Jul 31 05:39:29 PDT 2014
On Thu, Jul 31, 2014 at 02:03:31PM +0800, HuKeping wrote:
> Add arm specific parts to kdump kernel documentation.
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
> 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
So zImage is relocatable on arm?
> 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.
> 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.
>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.
> 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.
More information about the kexec