linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Bernhard Walle <bernhard@bwalle.de>
To: mohan@in.ibm.com
Cc: kexec@lists.infradead.org, ppcdev <linuxppc-dev@ozlabs.org>
Subject: Re: [PATCH] Reserve memory for kdump kernel within RMO region
Date: Wed, 25 Nov 2009 19:52:36 +0100	[thread overview]
Message-ID: <4B0D7CF4.8040402@bwalle.de> (raw)
In-Reply-To: <20091125131747.GA28857@in.ibm.com>

M. Mohan Kumar schrieb:
> Reserve memory for kdump kernel within RMO region
> 
> When the kernel size exceeds 32MB(observed with some distros), memory
> for kdump kernel can not be reserved as kdump kernel base is assumed to
> be 32MB always. When the kernel has CONFIG_RELOCATABLE option enabled,
> provide the feature to reserve the memory for kdump kernel anywhere in
> the RMO region.

Correct me if I'm wrong, but: CONFIG_RELOCATABLE is for the kernel that
gets loaded as crashkernel, not for the kernel that loads the
crashkernel. So it would be perfectly fine that a kernel that has not
CONFIG_RELOCATABLE set would load another kernel that has
CONFIG_RELOCATABLE set on an address != 32 M.

So it would be part of the command line to determine whether a fixed or
a variable address is used. The system configuration (or the admin)
knows both: if the kernel that should be loaded is relocatable (can be
detected with the x86 bzImage header or with the ELF type for vmlinux)
and it can also influence the boot command line.

To sum it up: I'm not against reserving it anywhere, I'm only against
making it dependent on CONFIG_RELOCATABLE which has another function.



Regards,
Bernhard

  reply	other threads:[~2009-11-25 19:02 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-25 13:17 [PATCH] Reserve memory for kdump kernel within RMO region M. Mohan Kumar
2009-11-25 18:52 ` Bernhard Walle [this message]
2009-11-26 11:12   ` M. Mohan Kumar
2009-11-26 19:26     ` Bernhard Walle
2009-11-27  8:35       ` M. Mohan Kumar
2009-11-27 11:51         ` Simon Horman
2009-11-27 12:54       ` M. Mohan Kumar
2009-11-27 18:39         ` Bernhard Walle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B0D7CF4.8040402@bwalle.de \
    --to=bernhard@bwalle.de \
    --cc=kexec@lists.infradead.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mohan@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).