On Monday 24 April 2017 07:30 PM, Michal Suchánek wrote:
On Mon, 24 Apr 2017 18:26:37 +0530
Hari Bathini <hbath...@linux.vnet.ibm.com> wrote:
Hi Michal.
On Monday 24 April 2017 03:54 PM, Michal Suchánek wrote:
On Fri, 21 Apr 2017 00:19:55 +0530
Hari Bathini <hbath...@linux.vnet.ibm.com> wrote:
On Wednesday 19 April 2017 07:38 PM, Michal Suchánek wrote:
On Wed, 19 Apr 2017 14:19:47 +1000
Michael Ellerman <m...@ellerman.id.au> wrote:
With the fadump_append= approach I posted in this response thread,
additional parameters are enforced when fadump is active. If f/w
supports appending additional parameters, it has to update
chosen/bootargs whenever fadump is active. Almost the same thing
except the dirty job is now done by f/w? Hence I thought
fadump_append= kernel parameter approach is simple and lesser of
the two evils? Am i missing something here..
The firmware already has to set the parameter by which the kernel
can tell it is a fadump kernel. Hence it already modifies the
devicetree for fadump and you have to rely on it to do so.
Right, devicetree is modified to include new 'ibm,kernel-dump' rtas
node informing that fadump is active.
The handover area which stores the additional parameters is
reserved by the running kernel so now you also have to rely on the
running kernel, the running kernel and fadum kernel having the same
idea about the location of handover area, the crashing kernel not
randomly overwriting the handover area, etc.
In short it is additional potential for trouble which can be
avoided.
I don't know if the firmware does protect the fadump reserved area
and devicetree from being randomly overwritten by the crashing
kernel but it is in the position to do so if desired. The handover
area is controlled by the crashing kernel and cannot have this
guarantee.
I thinks there is a mixup here..
I am no longer batting for handover area approach but
"fadump_append=" approach (suggested by Michael Ellerman in this
thread) where there is no need for a handover area but an additional
kernel parameter fadump_append=numa=off,nr_cpus=1.. which is a comma
separated list of parameters the user wants to enforce when fadump is
active.
I was trying to say that passing additional parameters with
'fadump_append=' kernel parameter is better over f/w changing the
chosen/bootargs node.
Ok, so a fadump specific parameter was just removed in
25031865553e5a2bd9b6e0a5d044952cfa2925d8 and with this we get one back.
I think you mean commit c2afb7ce9d088696427018ba2135b898058507b8
from linux-next. If so, yes.
If this is going to be added as an extra kernel parameter can't this be
passed to kdump kernel as well? Does kdump not have the same
restrictions?
kdump kernel is loaded with kexec and additional parameters can be
passed to it at the
time of loading. But fadump kernel boots like a regular kernel (through
f/w & bootloader,
resetting all the h/w) except that f/w guarantees to keep the memory
intact. So, there is
a need for a different approach to pass additional parameters in case of
fadump..
Thanks
Hari
