linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: Simon Horman <horms@verge.net.au>
Cc: Rob Landley <rlandley@parallels.com>,
	linux-doc@vger.kernel.org, kexec@lists.infradead.org,
	LKML <linux-kernel@vger.kernel.org>,
	"Ahmed S. Darwish" <darwish.07@gmail.com>,
	Haren Myneni <hbabu@us.ibm.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Eric Biederman <ebiederm@xmission.com>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH -next] Documentation: Improve crashkernel= description
Date: Mon, 7 Feb 2011 09:33:46 -0500	[thread overview]
Message-ID: <20110207143346.GB7437@redhat.com> (raw)
In-Reply-To: <20110207024238.GA22477@verge.net.au>

On Mon, Feb 07, 2011 at 11:42:38AM +0900, Simon Horman wrote:
> On Sun, Feb 06, 2011 at 08:25:20PM -0600, Rob Landley wrote:
> > On 02/06/2011 03:57 PM, Simon Horman wrote:
> > > On Sun, Feb 06, 2011 at 05:41:08PM +0200, Ahmed S. Darwish wrote:
> > >> (Also applicable over 2.6.38-rc3)
> > >>
> > >> Had to explore two C code files to make sense of the 'crashkernel='
> > >> kernel parameter values.  Improve the situation.
> > >>
> > >> Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
> > >> ---
> > >>
> > >> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> > >> index 89835a4..8f26b42 100644
> > >> --- a/Documentation/kernel-parameters.txt
> > >> +++ b/Documentation/kernel-parameters.txt
> > >> @@ -545,9 +545,12 @@ and is between 256 and 4096 characters. It is defined in the file
> > >>  			Format:
> > >>  			<first_slot>,<last_slot>,<port>,<enum_bit>[,<debug>]
> > >>  
> > >> -	crashkernel=nn[KMG]@ss[KMG]
> > >> -			[KNL] Reserve a chunk of physical memory to
> > >> -			hold a kernel to switch to with kexec on panic.
> > >> +	crashkernel=size[KMG][@offset[KMG]]
> > >> +			[KNL] Using kexec, Linux can switch to a 'crash kernel'
> > >> +			upon panic. This parameter reserves the physical
> > >> +			memory region [offset, offset + size] for that kernel
> > >> +			image. If the '@offset' part was ignored, Linux finds
> > >> +			a suitable crash image start address automatically.
> > > 
> > > I think this would be further improved as:
> > > 
> > > 			... If '@offset' is omitted then a suitable
> > > 			offset is selected automatically.
> > 
> > Suitable offset as in parses a known image type (ELF, bzImage, etc) to
> > find the start address?  Or just assumes the entry point and load
> > address are the same?
> 
> As in it finds a large enough area of contiguous free memory.
> I believe that originally it searched from the bottom of memory,
> it may be slightly smarter now.

Now it has been changed to search from top of the memory (atleast for x86) and
that caused few troubles. On 32bit it searches for memory under 512MB and
on x86_64, it searches for memory under 896MB.

Though hpa had suggested to enhance the command line syntax such that a
user specifies the upper bound on memory. Something like crashkernel=x < y.
So reserve X amount of memory below y MB. It boils down to same thing
that somebody has to know that what is the maximum physical memory
locaton kernel can boot from.

I think it is dependent on kernel as well as dependent on kexec-tools. I
am wondering if it is possible to make this info part of bzImage protocol
where kernel tells bootloader the maximum physical memory kernel can be
loaded at. I think this is off topic in the context of this patch, just
a thought...

Thanks
Vivek

  reply	other threads:[~2011-02-07 14:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-06 15:41 [PATCH -next] Documentation: Improve crashkernel= description Ahmed S. Darwish
2011-02-06 21:57 ` Simon Horman
2011-02-07  2:25   ` Rob Landley
2011-02-07  2:35     ` Eric W. Biederman
2011-02-07  2:42     ` Simon Horman
2011-02-07 14:33       ` Vivek Goyal [this message]
2011-02-07  4:14   ` Randy Dunlap
2011-02-07 11:30     ` [PATCH v2 " Ahmed S. Darwish
2011-02-07 11:41       ` Simon Horman
2011-02-07 14:25       ` Vivek Goyal
2011-02-07 16:01         ` [PATCH v3 " Ahmed S. Darwish
2011-02-08 18:50           ` Randy Dunlap

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=20110207143346.GB7437@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=darwish.07@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=hbabu@us.ibm.com \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=rlandley@parallels.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).