From: HuKeping <hukeping@huawei.com>
To: vgoyal@redhat.com, hbabu@us.ibm.com, rdunlap@infradead.org
Cc: peifeiyue@huawei.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: [PATCH V2] Add arm description to Documentation/kdump/kdump.txt
Date: Mon, 11 Aug 2014 12:14:39 +0800 [thread overview]
Message-ID: <1407730479-20800-1-git-send-email-hukeping@huawei.com> (raw)
----------------------------------------
Add arm specific parts to kdump kernel documentation.
It seem that we prefer to use nr_cpus=1 instead of maxcpus=1. but nr_cpus
does not work fine on arm.
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.
v1 -> v2:
- Add description about dump-capture kernel config options(Arch Dependent, arm).
- Add description about the defference between arm and the others.
on extended crashkernel syntax
Signed-off-by: Hu Keping <hukeping@huawei.com>
---
Documentation/kdump/kdump.txt | 37 ++++++++++++++++++++++++++++++++++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88d5a86..d07b902 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.
Building a relocatable kernel is advantageous from the point of view that
@@ -241,6 +241,14 @@ Dump-capture kernel config options (Arch Dependent, ia64)
kernel will be aligned to 64Mb, so if the start address is not then
any space below the alignment point will be wasted.
+Dump-capture kernel config options (Arch Dependent, arm)
+----------------------------------------------------------
+
+- To use a relocatable kernel,
+ Enable "AUTO_ZRELADDR" support under "Boot" options:
+
+ AUTO_ZRELADDR=y
+
Extended crashkernel syntax
===========================
@@ -256,6 +264,10 @@ The syntax is:
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=start-[end]
+Plesse note, on arm, the offset is required.
+ crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
+ range=start-[end]
+
'start' is inclusive and 'end' is exclusive.
For example:
@@ -296,6 +308,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@X". Note that the start address of the kernel
+ will be aligned to 128MiB (0x08000000), 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.
+
+
Load the Dump-capture Kernel
============================
@@ -315,7 +333,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 +350,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 +375,9 @@ For ppc64:
For s390x:
"1 maxcpus=1 cgroup_disable=memory"
+For arm:
+ "1 maxcpus=1 reset_devices"
+
Notes on loading the dump-capture kernel:
* By default, the ELF headers are stored in ELF64 format to support
--
1.8.5.5
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: HuKeping <hukeping@huawei.com>
To: <vgoyal@redhat.com>, <hbabu@us.ibm.com>, <rdunlap@infradead.org>
Cc: <kexec@lists.infradead.org>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <peifeiyue@huawei.com>
Subject: [PATCH V2] Add arm description to Documentation/kdump/kdump.txt
Date: Mon, 11 Aug 2014 12:14:39 +0800 [thread overview]
Message-ID: <1407730479-20800-1-git-send-email-hukeping@huawei.com> (raw)
----------------------------------------
Add arm specific parts to kdump kernel documentation.
It seem that we prefer to use nr_cpus=1 instead of maxcpus=1. but nr_cpus
does not work fine on arm.
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.
v1 -> v2:
- Add description about dump-capture kernel config options(Arch Dependent, arm).
- Add description about the defference between arm and the others.
on extended crashkernel syntax
Signed-off-by: Hu Keping <hukeping@huawei.com>
---
Documentation/kdump/kdump.txt | 37 ++++++++++++++++++++++++++++++++++---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88d5a86..d07b902 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.
Building a relocatable kernel is advantageous from the point of view that
@@ -241,6 +241,14 @@ Dump-capture kernel config options (Arch Dependent, ia64)
kernel will be aligned to 64Mb, so if the start address is not then
any space below the alignment point will be wasted.
+Dump-capture kernel config options (Arch Dependent, arm)
+----------------------------------------------------------
+
+- To use a relocatable kernel,
+ Enable "AUTO_ZRELADDR" support under "Boot" options:
+
+ AUTO_ZRELADDR=y
+
Extended crashkernel syntax
===========================
@@ -256,6 +264,10 @@ The syntax is:
crashkernel=<range1>:<size1>[,<range2>:<size2>,...][@offset]
range=start-[end]
+Plesse note, on arm, the offset is required.
+ crashkernel=<range1>:<size1>[,<range2>:<size2>,...]@offset
+ range=start-[end]
+
'start' is inclusive and 'end' is exclusive.
For example:
@@ -296,6 +308,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@X". Note that the start address of the kernel
+ will be aligned to 128MiB (0x08000000), 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.
+
+
Load the Dump-capture Kernel
============================
@@ -315,7 +333,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 +350,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 +375,9 @@ For ppc64:
For s390x:
"1 maxcpus=1 cgroup_disable=memory"
+For arm:
+ "1 maxcpus=1 reset_devices"
+
Notes on loading the dump-capture kernel:
* By default, the ELF headers are stored in ELF64 format to support
--
1.8.5.5
next reply other threads:[~2014-08-11 4:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-11 4:14 HuKeping [this message]
2014-08-11 4:14 ` [PATCH V2] Add arm description to Documentation/kdump/kdump.txt HuKeping
2014-08-11 16:36 ` Randy Dunlap
2014-08-11 16:36 ` Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1407730479-20800-1-git-send-email-hukeping@huawei.com \
--to=hukeping@huawei.com \
--cc=hbabu@us.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peifeiyue@huawei.com \
--cc=rdunlap@infradead.org \
--cc=vgoyal@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.