[PATCH 2/4] x86: Store memory ranges globally used for crash kernel to boot into
WANG Chao
chaowang at redhat.com
Fri Feb 14 01:30:57 EST 2014
On 02/13/14 at 04:46pm, Vivek Goyal wrote:
> On Thu, Feb 13, 2014 at 09:10:53PM +0800, WANG Chao wrote:
>
> [..]
> > @@ -230,6 +231,8 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
> > /* Only Dumping memory of type System RAM. */
> > if (memcmp(str, "System RAM\n", 11) == 0) {
> > type = RANGE_RAM;
> > + } else if (memcmp(str, "reserved\n", 9) == 0) {
> > + type = RANGE_RESERVED;
>
> Hi Chao,
>
> Can we take up the issue of passing reserved ranges to second kernel in
> a separate patchset. I had noticed higher memory usage due to that and
> it might have been something else.
OK. That can be done later.
>
> It might be easier to handle one thing at a time. Let us first start
> passing the memory range we pass on command line through bootparams and
> once that gets merged and stablizes, write a patchset to start passing
> reserved memory ranges if need be.
Cliff once sent a patch to pass reserved range to 2nd kernel (reverted
eventually due to its dependency on another patch which needed to
revert). In the patch he mentioned that some devices (PCI>0) on UV2
would fail without passing reserved range:
http://lists.infradead.org/pipermail/kexec/2013-February/007924.html
I don't dive into this issue. However I think as long as these reserved
ranges are provided by the firmware, it could be useful in 2nd kernel,
at least potentially.
Anyway this reserved ranges issue could be addressed later. I'll cut it
out in next update.
Thanks
WANG Chao
More information about the kexec
mailing list