[PATCH v2 1/2] fadump: reduce memory consumption for capture kernel

Michal Suchánek msuchanek at suse.de
Tue Apr 25 23:29:07 AEST 2017


On Tue, 25 Apr 2017 18:43:11 +0530
Hari Bathini <hbathini at linux.vnet.ibm.com> wrote:

> On Monday 24 April 2017 07:30 PM, Michal Suchánek wrote:
> > On Mon, 24 Apr 2017 18:26:37 +0530
> > Hari Bathini <hbathini at linux.vnet.ibm.com> wrote:
> >  
> >> Hi Michal.
> >>

> >>>     
> >> 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..
> 

I see, you can pass different commandline to the kdump kernel while
loading it with kexec but fadump kernel is booted same as normal kernel
until it looks at the devicetree so the extra arguments have to be
passed always and only appended to the commandline in the fadump case.

This sounds reasonable.

Thanks

Michal



More information about the Linuxppc-dev mailing list