| Message ID | 3c9bfb1df9bba481b753d8d630e4e3d45f986f04.1448403503.git.geoff@infradead.org |
|---|---|
| State | Superseded |
| Headers | show |
On Tue, Nov 24, 2015 at 10:25:34PM +0000, Geoff Levand wrote: > From: AKASHI Takahiro <takahiro.akashi@linaro.org> > > This patch adds arch specific descriptions about kdump usage on arm64 > to kdump.txt. > > Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> > --- > Documentation/kdump/kdump.txt | 32 +++++++++++++++++++++++++++++++- > 1 file changed, 31 insertions(+), 1 deletion(-) > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > index bc4bd5a..7d3fad0 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, > -s390x and arm architectures. > +s390x, arm and arm64 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 > @@ -249,6 +249,29 @@ Dump-capture kernel config options (Arch Dependent, arm) > > AUTO_ZRELADDR=y > > +Dump-capture kernel config options (Arch Dependent, arm64) > +---------------------------------------------------------- > + > +1) Disable symmetric multi-processing support under "Processor type and > + features": > + > + CONFIG_SMP=n > + > + (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line > + when loading the dump-capture kernel, see section "Load the Dump-capture > + Kernel".) SMP is now forced on, so please update this text. > +2) The maximum memory size on the dump-capture kernel must be limited by > + specifying: > + > + mem=X[MG] > + > + where X should be less than or equal to the size in "crashkernel=" > + boot parameter. Kexec-tools will automatically add this. > + > +3) Currently, kvm will not be enabled on the dump-capture kernel even > + if it is configured. > + > Extended crashkernel syntax > =========================== > > @@ -312,6 +335,8 @@ Boot into System Kernel > any space below the alignment point may be overwritten by the dump-capture kernel, > which means it is possible that the vmcore is not that precise as expected. > > + On arm64, use "crashkernel=Y[@X]". Note that the start address of > + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). > > Load the Dump-capture Kernel > ============================ > @@ -334,6 +359,8 @@ For s390x: > - Use image or bzImage > For arm: > - Use zImage > +For arm64: > + - Use vmlinux What? Why doesn't Image work? Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 12/16/2015 02:17 AM, Will Deacon wrote: > On Tue, Nov 24, 2015 at 10:25:34PM +0000, Geoff Levand wrote: >> From: AKASHI Takahiro <takahiro.akashi@linaro.org> >> >> This patch adds arch specific descriptions about kdump usage on arm64 >> to kdump.txt. >> >> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org> >> --- >> Documentation/kdump/kdump.txt | 32 +++++++++++++++++++++++++++++++- >> 1 file changed, 31 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt >> index bc4bd5a..7d3fad0 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, >> -s390x and arm architectures. >> +s390x, arm and arm64 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 >> @@ -249,6 +249,29 @@ Dump-capture kernel config options (Arch Dependent, arm) >> >> AUTO_ZRELADDR=y >> >> +Dump-capture kernel config options (Arch Dependent, arm64) >> +---------------------------------------------------------- >> + >> +1) Disable symmetric multi-processing support under "Processor type and >> + features": >> + >> + CONFIG_SMP=n >> + >> + (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line >> + when loading the dump-capture kernel, see section "Load the Dump-capture >> + Kernel".) > > SMP is now forced on, so please update this text. OK, I will fix it. >> +2) The maximum memory size on the dump-capture kernel must be limited by >> + specifying: >> + >> + mem=X[MG] >> + >> + where X should be less than or equal to the size in "crashkernel=" >> + boot parameter. Kexec-tools will automatically add this. >> + >> +3) Currently, kvm will not be enabled on the dump-capture kernel even >> + if it is configured. >> + >> Extended crashkernel syntax >> =========================== >> >> @@ -312,6 +335,8 @@ Boot into System Kernel >> any space below the alignment point may be overwritten by the dump-capture kernel, >> which means it is possible that the vmcore is not that precise as expected. >> >> + On arm64, use "crashkernel=Y[@X]". Note that the start address of >> + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). >> >> Load the Dump-capture Kernel >> ============================ >> @@ -334,6 +359,8 @@ For s390x: >> - Use image or bzImage >> For arm: >> - Use zImage >> +For arm64: >> + - Use vmlinux > > What? Why doesn't Image work? Actually it depends on kexec-tools, not the kernel. Initially Geoff implemented vmlinux support only, then recently Pratyush (RedHat) gave us a patch for "Image" support. So now Image should work. -Takahiro AKASHI > Will > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index bc4bd5a..7d3fad0 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, -s390x and arm architectures. +s390x, arm and arm64 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 @@ -249,6 +249,29 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y +Dump-capture kernel config options (Arch Dependent, arm64) +---------------------------------------------------------- + +1) Disable symmetric multi-processing support under "Processor type and + features": + + CONFIG_SMP=n + + (If CONFIG_SMP=y, then specify maxcpus=1 on the kernel command line + when loading the dump-capture kernel, see section "Load the Dump-capture + Kernel".) + +2) The maximum memory size on the dump-capture kernel must be limited by + specifying: + + mem=X[MG] + + where X should be less than or equal to the size in "crashkernel=" + boot parameter. Kexec-tools will automatically add this. + +3) Currently, kvm will not be enabled on the dump-capture kernel even + if it is configured. + Extended crashkernel syntax =========================== @@ -312,6 +335,8 @@ Boot into System Kernel any space below the alignment point may be overwritten by the dump-capture kernel, which means it is possible that the vmcore is not that precise as expected. + On arm64, use "crashkernel=Y[@X]". Note that the start address of + the kernel, X if explicitly specified, must be aligned to 2MiB (0x200000). Load the Dump-capture Kernel ============================ @@ -334,6 +359,8 @@ For s390x: - Use image or bzImage For arm: - Use zImage +For arm64: + - Use vmlinux If you are using a uncompressed vmlinux image then use following command to load dump-capture kernel. @@ -377,6 +404,9 @@ For s390x: For arm: "1 maxcpus=1 reset_devices" +For arm64: + "1 mem=X[MG] maxcpus=1 reset_devices" + Notes on loading the dump-capture kernel: * By default, the ELF headers are stored in ELF64 format to support