From: Horms <horms@verge.net.au>
To: Jay Lan <jlan@sgi.com>
Cc: "Zou, Nanhai" <nanhai.zou@intel.com>,
Andrew Morton <akpm@osdl.org>,
linux-ia64@vger.kernel.org, "Luck, Tony" <tony.luck@intel.com>,
fastboot@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] [PATCH] Kdump documentation update for 2.6.20: ia64 portion
Date: Sat, 13 Jan 2007 04:03:45 +0000 [thread overview]
Message-ID: <20070113040343.GA6227@verge.net.au> (raw)
In-Reply-To: <45A7E59F.7020207@sgi.com>
On Fri, Jan 12, 2007 at 11:46:39AM -0800, Jay Lan wrote:
> Horms wrote:
> > Hi,
> >
> > this patch fills in the portions for ia64 kexec.
> >
> > I'm actually not sure what options are required for the dump-capture
> > kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
> > Or more to the point, I'm not sure if irqpoll is needed or not.
> >
> > This patch requires the documentation patch update that Vivek Goyal has
> > been circulating, and I believe is currently in mm. Feel free to fold it
> > into that change if it makes things easier for anyone.
> >
> > Take II
> >
> > Nanhai,
> >
> > I have noted that vmlinux.gz may also be used. And added a note about the
> > kernel being able to automatically place the crashkernel region.
> > Furthermore, I added a note that if manually specified, the region should
> > be 64Mb aligned to avoid wastage. I notice that the auto placement code
> > uses 64Mb. But is this strictly neccessary for all page sizes?
> >
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > Index: linux-2.6/Documentation/kdump/kdump.txt
> > =================================> > --- linux-2.6.orig/Documentation/kdump/kdump.txt 2007-01-12 17:45:19.000000000 +0900
> > +++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 17:59:42.000000000 +0900
> > @@ -17,7 +17,7 @@
> > memory image to a dump file on the local disk, or across the network to
> > a remote system.
> >
> > -Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
> > +Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
> > architectures.
> >
> > When the system kernel boots, it reserves a small section of memory for
> > @@ -229,7 +229,23 @@
> >
> > Dump-capture kernel config options (Arch Dependent, ia64)
> > ----------------------------------------------------------
> > -(To be filled)
> > +
> > +- No specific options are required to create a dump-capture kernel
> > + for ia64, other than those specified in the arch idependent section
> > + above. This means that it is possible to use the system kernel
> > + as a dump-capture kernel if desired.
> > +
> > + The crashkernel region can be automatically placed by the system
> > + kernel at run time. This is done by specifying the base address as 0,
> > + or omitting it all together.
>
> In my testing, i found the base address was ignored. Whatever value
> specified was fine. Not necessary to be 0. But i guess it is fine to
> give people a guideline telling them to specify 0.
I submitted a patch to honour non-zero base addresses,
I'm pretty sure it is in there now.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
WARNING: multiple messages have this Message-ID (diff)
From: Horms <horms@verge.net.au>
To: Jay Lan <jlan@sgi.com>
Cc: "Zou, Nanhai" <nanhai.zou@intel.com>,
Andrew Morton <akpm@osdl.org>,
linux-ia64@vger.kernel.org, "Luck, Tony" <tony.luck@intel.com>,
fastboot@lists.osdl.org, linux-kernel@vger.kernel.org
Subject: Re: [Fastboot] [PATCH] Kdump documentation update for 2.6.20: ia64 portion
Date: Sat, 13 Jan 2007 13:03:45 +0900 [thread overview]
Message-ID: <20070113040343.GA6227@verge.net.au> (raw)
In-Reply-To: <45A7E59F.7020207@sgi.com>
On Fri, Jan 12, 2007 at 11:46:39AM -0800, Jay Lan wrote:
> Horms wrote:
> > Hi,
> >
> > this patch fills in the portions for ia64 kexec.
> >
> > I'm actually not sure what options are required for the dump-capture
> > kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
> > Or more to the point, I'm not sure if irqpoll is needed or not.
> >
> > This patch requires the documentation patch update that Vivek Goyal has
> > been circulating, and I believe is currently in mm. Feel free to fold it
> > into that change if it makes things easier for anyone.
> >
> > Take II
> >
> > Nanhai,
> >
> > I have noted that vmlinux.gz may also be used. And added a note about the
> > kernel being able to automatically place the crashkernel region.
> > Furthermore, I added a note that if manually specified, the region should
> > be 64Mb aligned to avoid wastage. I notice that the auto placement code
> > uses 64Mb. But is this strictly neccessary for all page sizes?
> >
> > Signed-off-by: Simon Horman <horms@verge.net.au>
> >
> > Index: linux-2.6/Documentation/kdump/kdump.txt
> > ===================================================================
> > --- linux-2.6.orig/Documentation/kdump/kdump.txt 2007-01-12 17:45:19.000000000 +0900
> > +++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 17:59:42.000000000 +0900
> > @@ -17,7 +17,7 @@
> > memory image to a dump file on the local disk, or across the network to
> > a remote system.
> >
> > -Kdump and kexec are currently supported on the x86, x86_64, ppc64 and IA64
> > +Kdump and kexec are currently supported on the x86, x86_64, ppc64 and ia64
> > architectures.
> >
> > When the system kernel boots, it reserves a small section of memory for
> > @@ -229,7 +229,23 @@
> >
> > Dump-capture kernel config options (Arch Dependent, ia64)
> > ----------------------------------------------------------
> > -(To be filled)
> > +
> > +- No specific options are required to create a dump-capture kernel
> > + for ia64, other than those specified in the arch idependent section
> > + above. This means that it is possible to use the system kernel
> > + as a dump-capture kernel if desired.
> > +
> > + The crashkernel region can be automatically placed by the system
> > + kernel at run time. This is done by specifying the base address as 0,
> > + or omitting it all together.
>
> In my testing, i found the base address was ignored. Whatever value
> specified was fine. Not necessary to be 0. But i guess it is fine to
> give people a guideline telling them to specify 0.
I submitted a patch to honour non-zero base addresses,
I'm pretty sure it is in there now.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
next prev parent reply other threads:[~2007-01-13 4:03 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-12 6:06 [PATCH] Kdump documentation update for 2.6.20: kexec-tools update Horms
2007-01-12 6:06 ` Horms
2007-01-12 6:07 ` [PATCH] Kdump documentation update for 2.6.20: ia64 portion Horms
2007-01-12 6:07 ` Horms
2007-01-12 8:34 ` Zou, Nanhai
2007-01-12 8:34 ` Zou, Nanhai
2007-01-12 9:00 ` Horms
2007-01-12 9:00 ` Horms
2007-01-12 10:33 ` Andreas Schwab
2007-01-12 10:33 ` Andreas Schwab
2007-01-13 4:05 ` Horms
2007-01-13 4:05 ` Horms
2007-01-12 19:46 ` [Fastboot] [PATCH] Kdump documentation update for 2.6.20: ia64 Jay Lan
2007-01-12 19:46 ` [Fastboot] [PATCH] Kdump documentation update for 2.6.20: ia64 portion Jay Lan
2007-01-13 4:03 ` Horms [this message]
2007-01-13 4:03 ` 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=20070113040343.GA6227@verge.net.au \
--to=horms@verge.net.au \
--cc=akpm@osdl.org \
--cc=fastboot@lists.osdl.org \
--cc=jlan@sgi.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nanhai.zou@intel.com \
--cc=tony.luck@intel.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 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.