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:
Michal Suchánek <msucha...@suse.de> writes:
On Mon, 17 Apr 2017 20:43:02 +0530
Hari Bathini <hbath...@linux.vnet.ibm.com> wrote:
On Friday 14 April 2017 01:28 AM, Michal Suchánek wrote:
more (optional) properties cannot be added?
Kernel change seems simple over f/w enhancement..
That certainly looks so when you are a kernel developer and can
implement the change yourself compared to convincing some firmware
developer that this feature makes sense.
On the other hand, the proposed kernel-only solution introduces
requirement that the maintainer does not like.
For the platform as a whole does it make more sense to add a hack
to the kernel or does it make sense to enhance the firmware to
provide more options for firmware-assisted dump?
Unfortunately it doesn't really matter, because there is firmware
out there that implements the current behaviour and will never be
updated. So we have to work with what's there.
It's not that with the existing firmware fadump does not work. It
just uses more memory than needed. So if new firmware revision
allows more flexibility it will work for people with updated
firmware and people with outdated firmware will get the current
behavior.
The memory saving is only significant for big systems so only people
running those will get significant improvement from the updated
firmware.
Hi Michal,
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.
Thanks
Hari
