All of lore.kernel.org
 help / color / mirror / Atom feed
From: Horms <horms@verge.net.au>
To: linux-ia64@vger.kernel.org
Subject: Re: [PATCH] ia64, kexec: allow base of crashkernel to be auto-discovered
Date: Thu, 29 Jun 2006 01:44:02 +0000	[thread overview]
Message-ID: <20060629014359.GD14402@verge.net.au> (raw)
In-Reply-To: <20060628110052.GA11751@verge.net.au>

On Thu, Jun 29, 2006 at 06:38:22AM +0800, Zou Nan hai wrote:
> On Wed, 2006-06-28 at 19:00, Horms wrote:
> > The crashkernel command line parameter accepts a size and base address for
> > the memory region that is reserved to be used as the memory space for a
> > crash kernel. At this time, on some architectures, notably i386 and x86_64,
> > the base address of the crash kernel needs to be modified at compile time
> > to match the base address passed to crashkernel. However, on ia64 the
> > crash kernel does not need to be relocated at compile time, thus
> > there the base address of the crashkernel region does not need to be fixed.
> > 
> > This patch allows the base address of crashkernel to be determined at boot
> > time if the base address passed on the command line is 0. Otherwise
> > the specified base address will be used, as is currently the case.
> > 
> > The advantage is that the region layout may vary from machine to machine,
> > and finding a place for the crashkernel is a manual process. This eliminates
> > that manual work, and I expect will make life slightly easier for distros.
> > 
> > I would like to note that currently it will try and place the crashkernel
> > region inside the first "System RAM" region that has space. I am not
> > sure if there should be a lower or upper bond on the crashkernel base address,
> > but it will be trivial to add to the arguments passed to allocate_region()
> > if necessary.
> > 
>   I think there is no upper and lower limit of crash kernel base
> address, but the base address should be aligned to 64M.
> 
> which is max(max possible IA64_GRANULE_SIZE, KERNEL_TR_PAGE_SIZE)

Ok, thanks. That should be an easy enough change. Can someone confirm that it
is necessary? Anecdotally, on my system the region ended up at 48f0000
(~72Mb) and kdump does seem to work.

-- 
Horms                                           
H: http://www.vergenet.net/~horms/          W: http://www.valinux.co.jp/en/


  parent reply	other threads:[~2006-06-29  1:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-28 11:00 [PATCH] ia64, kexec: allow base of crashkernel to be auto-discovered Horms
2006-06-28 22:38 ` [PATCH] ia64, kexec: allow base of crashkernel to be Zou Nan hai
2006-06-29  0:29 ` Zou Nan hai
2006-06-29  1:44 ` Horms [this message]
2006-06-29  4:23 ` [PATCH] ia64, kexec: allow base of crashkernel to be auto-discovered Horms
2006-06-29 21:51 ` Luck, Tony
2006-06-30  3:56 ` Horms
2006-07-05  0:42 ` Horms
2006-07-05 19:16 ` Luck, Tony
2006-07-06  8:24 ` Horms

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=20060629014359.GD14402@verge.net.au \
    --to=horms@verge.net.au \
    --cc=linux-ia64@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.