mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Horms <horms@verge.net.au>
To: Andrew Morton <akpm@osdl.org>
Cc: Valdis.Kletnieks@vt.edu, fastboot@lists.osdl.org,
	linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] Stupid kexec/kdump question...
Date: Wed, 27 Sep 2006 14:27:38 +0900	[thread overview]
Message-ID: <20060927052737.GA17214@verge.net.au> (raw)
In-Reply-To: <20060926221029.d9e87650.akpm@osdl.org>

On Tue, Sep 26, 2006 at 10:10:29PM -0700, Andrew Morton wrote:
> On Tue, 26 Sep 2006 11:25:06 -0400
> Valdis.Kletnieks@vt.edu wrote:
> 
> > OK, I'm running a Fedora Core 6 (rawhide actually) box with -18-mm1 kernel.
> > I've installed kexec-tools and similar, and am trying to get the kernels
> > built following the hints in Documentation/kdump/kdump.txt, but a few
> > questions arise:
> > 
> > 1) Other than the fact that the Fedora userspace looks for a
> > ${kernelvers}kdump kernel, is there any reason the kdump kernel has
> > to match the running one, or can an older kernel be used?

The post-crash kernel is not realy dependant on the pre-crash kernel.
What is important is that either the kernel is relocatable
(which is being worked on for x86 and i386), or it is compiled to
run at a non-default address and that address corresponds
to the region reserved by the crashkernel command line parameter
passed to the pre-crash kernel.

The post-crash kernel will also need CONFIG_CRASH_DUMP 
and likely CONFIG_PROC_VMCORE

> > 2) I'm presuming that a massively stripped down kernel (no sound support,
> > no netfilter, no etc) that just has what's needed to mount the dump location
> > is sufficient?

Yes

> > 3) The docs recommend 'crashkernel=64M@16M', but that's 8% of my memory.
> > What will happen if I try '16M@16M' instead?  Just slower copying due to
> > a smaller buffer cache space, or something more evil?

There is a lower bound to how small you can make the space, which
is basically how little memory space your post-crash kernel needs.
16M is probably pushing it, but 32M should be more than possible.
Experimentation is really the order of the day here.

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


  reply	other threads:[~2006-09-27  5:28 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-26 15:25 Valdis.Kletnieks
2006-09-27  5:10 ` Andrew Morton
2006-09-27  5:27   ` Horms [this message]
2006-09-27  8:00     ` [Fastboot] " Eric W. Biederman
2006-09-27 12:51       ` Valdis.Kletnieks
2006-09-27 13:11         ` Vivek Goyal
2006-09-27 13:24         ` Vivek Goyal
2006-09-27 14:44           ` Valdis.Kletnieks

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=20060927052737.GA17214@verge.net.au \
    --to=horms@verge.net.au \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=akpm@osdl.org \
    --cc=fastboot@lists.osdl.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®