kdump info request

[Mukker, Atul]

Please see me response embedded below...

> Thanks for the reply. I guess we have pretty much nailed down device
bringup sequence when loading under capture kernel. Our concern is: the
capture kernel has a significant smaller memory footprint. Our RAID
driver itself has a large memory requirement, some of which could fail
allocation when loaded under the capture kernel.
> 
> If we could somehow determine that we are being called in context of
capture kernel, we can dynamically lower driver memory requirement (at
cost of lower IO throughout of-course, which is ok for this brief
context).

You can parse the command line and look for presence of elfcorehdr=
option.
This is internally appended to command line by kexec tools to tell
capture
kernel the address of ELF core headers.


[AM] Is this a standard way? Doesn't look like one. According to
kernel-parameters.txt, kexec would "generally" pass this option to
kernel command line. Can we look at "struct resource crashk_res" and
check if start and end member have different value, which indicates
capture kernel?

What's the memory allocation requirement of current RAID driver? How
much
memory you are reserving for capture kernel? Are you already seeing the
memory allocation failure?

[AM] Our normal runtime memory is about 20MB. For the test beds, we use
"crashkernel=192M at 16M". We have not yet seen the allocation failure but
we would like to build the fallback mechanism if it does fail under
capture kernel. Only if we are not able to get the normal runtime
memory, we plan to switch to a lower memory model.

I feel until and unless memory requirements are huge, we should not
compromise with IO throughput. Capability to save the dump to disk as
fast
as possible to reduce the down time is also an important consideration.

[AM] We believe our normal runtime memory requirement is significant.
Also, even with the lower memory, there would not be a noticeable dump
time difference since lot of memory is for supporting multiple
outstanding commands in driver's raid core and other raid operations,
which will not be running under capture kernel. Thanks again for your
feedback.

Thanks
Vivek

> 
> Thanks
> -Atul
> 
> -----Original Message-----
> From: Vivek Goyal [mailto:vgoyal at in.ibm.com]
> Sent: Tue 9/18/2007 9:53 PM
> To: Mukker, Atul
> Cc: vgoyal at in.ibm.com; Kexec Mailing List
> Subject: Re: kdump info request
>  
> On Tue, Sep 18, 2007 at 03:13:42PM -0600, Mukker, Atul wrote:
> > Hello Vivek, Hari:
> > 
> >  
> > 
> > Excuse me for contacting you direct, but seems like you 2 can point
me
> > to a right direction for a kdump question we have.
> > 
> >  
> > 
> > We are trying to make sure our RAID driver works ok when kernel is
> > loaded with kdump. Is there a way for driver to detect this
condition;
> > that is, current kernel is running with kdump. We need this
information
> > so we can scale down certain operations in the driver.
> > 
> 
> Hi Atul,
> 
> What do you mean by detecting if current kernel is running with kdump?
Do 
> you mean that you want to know the moment somebody loads a capture
kernel
> by kexec -p and driver will change some of its behaviour?
> 
> I think that's not the right way to go about. Explain the issue
> a little bit in detail.
> 
> Generally drivers run into issues while initializing in second kernel
and
> one of the way to handle it is reset the device before going further
with
> initialization. I am hoping your RAID controller provides some kind of
> reset mechanism from software.
> 
> Thanks
> Vivek
> 
>