From: Stanislaw Gruszka <stf_xl@wp.pl>
Subject: Re: kdump from x86_64 using i386 capture kernel
Date: Sat, 5 Jan 2008 11:52:53 +0100
References: <200801041346.38120.stf_xl@wp.pl> <200801041600.26866.stf_xl@wp.pl>
	<20080104154931.GA8804@hmsendeavour.rdu.redhat.com>
In-Reply-To: <20080104154931.GA8804@hmsendeavour.rdu.redhat.com>
MIME-Version: 1.0
Content-Disposition: inline
Message-Id: <200801051152.53550.stf_xl@wp.pl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: kexec-bounces@lists.infradead.org
Errors-To: kexec-bounces+dwmw2=infradead.org+dwmw2=infradead.org@lists.infradead.org
To: Neil Horman <nhorman@redhat.com>
Cc: kexec@lists.infradead.org

On Friday 04 January 2008 16:49, Neil Horman wrote:
> On Fri, Jan 04, 2008 at 04:00:26PM +0100, Stanislaw Gruszka wrote:
> > On Friday 04 January 2008 14:55, Neil Horman wrote:
> > > > It is possible to achieve valid vmcore when first is x86_64 and capture 
> > > > is i386 ?
> > > Possible I think, but not reliable.  If oldmem has regions to capture above the
> > > 4GB range, a 386 kernel won't be able to access those addresses, and as such,
> > > you won't get a complete vmcore.
> > Uffff, I missed this fact. 
> > 
> > > I'm also confused about what exactly you are trying to accomplish.  Why are you
> > > trying to use an x86 kernel to capture a x86_64 vmcore?  The available
> > System load from flash and there is limited space. I tried to do one capture
> > kernel, but see this was bad idea. I will scarify another 2MB and make separate
> > image for x86_64. 
> > 
> 
> I'm still not quite understanding, the kernel image that you used to initally
> boot the box should be suitable for loading as the kdump image.  Even if you're
> using i386 instead of x86_64 as your kdump kernel, you still need to maintain
> two images.
Turn on CONFIG_RELOCATABLE and using same kernel for work and capture is 
the best for size requirement. However size is not only one requirement, I need 
to capture kernel work reliably. RELOCATABLE is masked as experimental, so
I like to avoid it. Additionally, if I use same kernel for capture, it could
have same bugs and crash too during start up. So I decided to use separate
2.6.16.y kernel for capture. This version, maintained by Adrian Bunk, have many
bug fixes and I think is very stable. Kernel config is different too, I do not only
remove device drivers and modules, but also hardcoded things from Process Type
and Features, Power Management and so on ... , just enough to boot and setup
network with minimal probability of crash.

Stanislaw Gruszka

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec