diff options
author | Hari Bathini <hbathini@linux.ibm.com> | 2019-09-11 17:47:07 +0300 |
---|---|---|
committer | Michael Ellerman <mpe@ellerman.id.au> | 2019-09-13 17:04:41 +0300 |
commit | 8468d155450c89adbb400cdae42bd4095f3045a9 (patch) | |
tree | 3ef6c934629d125c019968e2d0c3bd17f74edfce /Documentation/powerpc | |
parent | 7f0ad11d3fb948a0d7770bd38ae17a51413c3dac (diff) | |
download | linux-8468d155450c89adbb400cdae42bd4095f3045a9.tar.xz |
powerpc/fadump: Improve fadump documentation
The figures depicting FADump's (Firmware-Assisted Dump) memory layout
are missing some finer details like different memory regions and what
they represent. Improve the documentation by updating those details.
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/156821322070.5656.8194734198500730487.stgit@hbathini.in.ibm.com
Diffstat (limited to 'Documentation/powerpc')
-rw-r--r-- | Documentation/powerpc/firmware-assisted-dump.rst | 61 |
1 files changed, 33 insertions, 28 deletions
diff --git a/Documentation/powerpc/firmware-assisted-dump.rst b/Documentation/powerpc/firmware-assisted-dump.rst index 9ca12830a48e..563c021df539 100644 --- a/Documentation/powerpc/firmware-assisted-dump.rst +++ b/Documentation/powerpc/firmware-assisted-dump.rst @@ -76,8 +76,9 @@ as follows: there is crash data available from a previous boot. During the early boot OS will reserve rest of the memory above boot memory size effectively booting with restricted memory - size. This will make sure that the second kernel will not - touch any of the dump memory area. + size. This will make sure that this kernel (also, referred + to as second kernel or capture kernel) will not touch any + of the dump memory area. - User-space tools will read /proc/vmcore to obtain the contents of memory, which holds the previous crashed kernel dump in ELF @@ -128,42 +129,46 @@ space memory except the user pages that were present in CMA region:: o Memory Reservation during first kernel - Low memory Top of memory - 0 boot memory size | - | | |<--Reserved dump area -->| | - V V | Permanent Reservation | V - +-----------+----------/ /---+---+----+-----------+----+------+ - | | |CPU|HPTE| DUMP |ELF | | - +-----------+----------/ /---+---+----+-----------+----+------+ - | ^ - | | - \ / - ------------------------------------------- - Boot memory content gets transferred to - reserved area by firmware at the time of - crash + Low memory Top of memory + 0 boot memory size |<--Reserved dump area --->| | + | | | (Permanent Reservation) | | + V V | | V + +-----------+----------/ /---+---+----+--------+---+----+------+ + | | |CPU|HPTE| DUMP |HDR|ELF | | + +-----------+----------/ /---+---+----+--------+---+----+------+ + | ^ ^ + | | | + \ / | + ----------------------------------- FADump Header + Boot memory content gets transferred (meta area) + to reserved area by firmware at the + time of crash + Fig. 1 + o Memory Reservation during second kernel after crash - Low memory Top of memory - 0 boot memory size | - | |<------------- Reserved dump area ----------- -->| - V V V - +-----------+----------/ /---+---+----+-----------+----+------+ - | | |CPU|HPTE| DUMP |ELF | | - +-----------+----------/ /---+---+----+-----------+----+------+ + Low memory Top of memory + 0 boot memory size | + | |<----------- Crash preserved area --------------->| + V V |<-- Reserved dump area -->| V + +-----------+----------/ /---+---+----+--------+---+----+------+ + | | |CPU|HPTE| DUMP |HDR|ELF | | + +-----------+----------/ /---+---+----+--------+---+----+------+ | | V V Used by second /proc/vmcore kernel to boot Fig. 2 -Currently the dump will be copied from /proc/vmcore to a -a new file upon user intervention. The dump data available through -/proc/vmcore will be in ELF format. Hence the existing kdump -infrastructure (kdump scripts) to save the dump works fine with -minor modifications. +Currently the dump will be copied from /proc/vmcore to a new file upon +user intervention. The dump data available through /proc/vmcore will be +in ELF format. Hence the existing kdump infrastructure (kdump scripts) +to save the dump works fine with minor modifications. KDump scripts on +major Distro releases have already been modified to work seemlessly (no +user intervention in saving the dump) when FADump is used, instead of +KDump, as dump mechanism. The tools to examine the dump will be same as the ones used for kdump. |