| Message ID | 156327673568.27462.12962666023309715458.stgit@hbathini.in.ibm.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Add FADump support on PowerNV platform | expand |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | success | Successfully applied on branch next (f5c20693d8edcd665f1159dc941b9e7f87c17647) |
| snowpatch_ozlabs/checkpatch | success | total: 0 errors, 0 warnings, 0 checks, 98 lines checked |
On 7/16/19 5:02 PM, Hari Bathini wrote: > 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> > --- > Documentation/powerpc/firmware-assisted-dump.txt | 65 ++++++++++++---------- > 1 file changed, 35 insertions(+), 30 deletions(-) > > diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt > index 0c41d6d..e9b4e3c 100644 > --- a/Documentation/powerpc/firmware-assisted-dump.txt > +++ b/Documentation/powerpc/firmware-assisted-dump.txt This will have to be rebased now on firmware-assisted-dump.rst. However Changes looks good to me. Thanks, -Mahesh. > @@ -74,8 +74,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 > @@ -125,48 +126,52 @@ 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 | (Preserve area) | 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 | > + | |<------------- Reserved dump area --------------->| > + V V |<---- Preserve 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. > > How to enable firmware-assisted dump (fadump): > -------------------------------------- > +--------------------------------------------- > > 1. Set config option CONFIG_FA_DUMP=y and build kernel. > 2. Boot into linux kernel with 'fadump=on' kernel cmdline option. > @@ -189,7 +194,7 @@ NOTE: 1. 'fadump_reserve_mem=' parameter has been deprecated. Instead > old behaviour. > > Sysfs/debugfs files: > ------------- > +------------------- > > Firmware-assisted dump feature uses sysfs file system to hold > the control files and debugfs file to display memory reserved region. >
diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt index 0c41d6d..e9b4e3c 100644 --- a/Documentation/powerpc/firmware-assisted-dump.txt +++ b/Documentation/powerpc/firmware-assisted-dump.txt @@ -74,8 +74,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 @@ -125,48 +126,52 @@ 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 | (Preserve area) | 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 | + | |<------------- Reserved dump area --------------->| + V V |<---- Preserve 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. How to enable firmware-assisted dump (fadump): -------------------------------------- +--------------------------------------------- 1. Set config option CONFIG_FA_DUMP=y and build kernel. 2. Boot into linux kernel with 'fadump=on' kernel cmdline option. @@ -189,7 +194,7 @@ NOTE: 1. 'fadump_reserve_mem=' parameter has been deprecated. Instead old behaviour. Sysfs/debugfs files: ------------- +------------------- Firmware-assisted dump feature uses sysfs file system to hold the control files and debugfs file to display memory reserved region.
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> --- Documentation/powerpc/firmware-assisted-dump.txt | 65 ++++++++++++---------- 1 file changed, 35 insertions(+), 30 deletions(-)