| Message ID | 20160907042908.6232-7-takahiro.akashi@linaro.org |
|---|---|
| State | New |
| Headers | show |
On Fri, Sep 16, 2016 at 05:08:28PM +0100, James Morse wrote: > Hi Akashi, > > On 07/09/16 05:29, AKASHI Takahiro wrote: > > This patch adds arch specific descriptions about kdump usage on arm64 > > to kdump.txt. > > > diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt > > > @@ -249,6 +249,13 @@ Dump-capture kernel config options (Arch Dependent, arm) > > > > AUTO_ZRELADDR=y > > > > +Dump-capture kernel config options (Arch Dependent, arm64) > > +---------------------------------------------------------- > > + > > +- Please note that kvm of the dump-capture kernel will not be enabled > > + on non-VHE systems even if it is configured. This is because the CPU > > + cannot be reset to EL2 on panic. > > Nit: > cannot be -> will not be OK. > We could try to do this, but its more code that could prevent us reaching the > kdump kernel, so we choose not to. > > > > @@ -370,6 +381,9 @@ For s390x: > > For arm: > > "1 maxcpus=1 reset_devices" > > > > +For arm64: > > + "1 maxcpus=1 reset_devices" > > + > > 'maxcpus=1' is a bit fragile. Since 44dbcc93ab67145 ("arm64: Fix behavior of > maxcpus=N") udev on ubuntu vivid (running on Juno) has taken it upon itself to > bring the secondary cores online, even when booted with 'maxcpus=1'. > > Can we change the recomendation to "1 nosmp reset_devices"? Well, I have no strong opinion here, but I'm not quite sure whether this change does make any difference in practice. Looking at kernel/smp.c, the only difference is setup_max_cpus. But given that arch_disable_smp_support() is null and smp_cpus_done() ignores "max_cpus" on arm64, I don't think that the change is very meaningful. I might miss something. Thanks, -Takahiro AKASHI > > Thanks, > > James > _______________________________________________ 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 88ff63d..c090531 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,13 @@ Dump-capture kernel config options (Arch Dependent, arm) AUTO_ZRELADDR=y +Dump-capture kernel config options (Arch Dependent, arm64) +---------------------------------------------------------- + +- Please note that kvm of the dump-capture kernel will not be enabled + on non-VHE systems even if it is configured. This is because the CPU + cannot be reset to EL2 on panic. + Extended crashkernel syntax =========================== @@ -305,6 +312,8 @@ Boot into System Kernel kernel will automatically locate the crash kernel image within the first 512MB of RAM if X is not given. + 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 ============================ @@ -327,6 +336,8 @@ For s390x: - Use image or bzImage For arm: - Use zImage +For arm64: + - Use vmlinux or Image If you are using a uncompressed vmlinux image then use following command to load dump-capture kernel. @@ -370,6 +381,9 @@ For s390x: For arm: "1 maxcpus=1 reset_devices" +For arm64: + "1 maxcpus=1 reset_devices" + Notes on loading the dump-capture kernel: * By default, the ELF headers are stored in ELF64 format to support