kdump info request

[Mukker, Atul]

Thanks for the information and the effort.

We need to support all currently shipping products with kdump support
available (read Red Hat and SuSE) so sooner it makes into to the
upstream kernel the better it is.

So, today there is no alternative way to find out if the driver is being
loaded under kdump restrictive environment?

Thanks
-Atul

-----Original Message-----
From: Randy Dunlap [mailto:rdunlap at xenotime.net] 
Sent: Monday, October 01, 2007 11:13 AM
To: Mukker, Atul
Cc: vgoyal at in.ibm.com; Moore, Eric; Kexec Mailing List
Subject: Re: kdump info request

On Mon, 1 Oct 2007 08:35:28 -0600 Mukker, Atul wrote:

> Hello Randy,
> 
> I tried this today but did not succeed :-( Can you please see the logs
> appended below and point out what I might be doing wrong? This is on a
> Red Hat 5 system.
> 
> Thanks
> -Atul

Hi Atul,

I can see the problem without looking at your module.
'saved_command_line' is only exported for modules in the sparc & 
sparc64 architectures.  What kernel version(s) do you need this
for?  Is 2.6.24 and later good enough if we can get the symbol
exported in that timeframe?

Vivek, do you want to submit a patch for this and also remove these
lines:
./arch/sparc/kernel/sparc_ksyms.c:231:EXPORT_SYMBOL(saved_command_line);
./arch/sparc64/kernel/sparc64_ksyms.c:250:EXPORT_SYMBOL(saved_command_li
ne);

or should I attempt it?


> +++++++++++
> Sample code
> +++++++++++
> #include <linux/init.h>
> #include <linux/version.h>
> #include <linux/module.h>
> 
> MODULE_AUTHOR("LSI Corporation");
> MODULE_VERSION("1.0");
> MODULE_DESCRIPTION("Kernel Command Line");
> MODULE_LICENSE("GPL");
> 
> static int __init cline_init(void)
> {
> 	printk("enter module:[%s]\n", saved_command_line);
> 	return 0;
> }
> 
> static void __exit cline_exit(void)
> {
> 	printk("exit module.\n");
> }
> 
> module_init(cline_init);
> module_exit(cline_exit);
> 
> ++++++++
> Makefile
> ++++++++
> obj-m	+= cline.o
> 
> +++++++++
> Build log
> +++++++++
> 
> make: Entering directory `/usr/src/kernels/2.6.18-8.el5-i686'
>   LD
> /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/built-in.o
>   CC [M]
/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.o
>   Building modules, stage 2.
>   MODPOST
> WARNING: "saved_command_line"
> [/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko]
> undefined!
>   CC
> /usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.mod.o
>   LD [M]
/usr/src/kernels/2.6.18-8.el5-i686/drivers/scsi/cline/cline.ko
> make: Leaving directory `/usr/src/kernels/2.6.18-8.el5-i686'
> 
> 
> -----Original Message-----
> From: Randy Dunlap [mailto:rdunlap at xenotime.net] 
> Sent: Saturday, September 22, 2007 2:36 PM
> To: Mukker, Atul
> Cc: vgoyal at in.ibm.com; Moore, Eric; Kexec Mailing List
> Subject: Re: kdump info request
> 
> On Fri, 21 Sep 2007 06:48:01 -0600 Mukker, Atul wrote:
> 
> > One more question, and hopefully I will not bug you further on this
> :-)
> > 
> > How exactly do you parse the kernel parameters? I thought it would
be
> > plain simple, but seems like the command line string is not
available
> to
> > SCSI driver like ours, or I am missing something?
> 
> #include <linux/init.h>  // for extern of 'saved_command_line'
pointer.
> 
> and use calls to any functions in lib/cmdline.c or write your
> own functions.  Should be fairly simple to scan for a fixed string
> of "elfcorehdr=".
> You don't care about the variable parameters.. or do you?
> 
> 
> > Thanks
> > -Atul 
> > 
> > -----Original Message-----
> > From: Vivek Goyal [mailto:vgoyal at in.ibm.com] 
> > Sent: Friday, September 21, 2007 12:15 AM
> > To: Mukker, Atul
> > Cc: Kexec Mailing List; Moore, Eric
> > Subject: Re: kdump info request
> > 
> > On Wed, Sep 19, 2007 at 07:26:19AM -0600, Mukker, Atul wrote:
> > [..]
> > > > 
> > > > 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?
> > > 
> > 
> > Well, nobody else so far has had such requirements so can't say if
> this
> > is standard way. But this is the best way I can think of so far.
> > 
> > Using crashk_res will not work. Not all users will use kdump and
will
> > not
> > reserve any memory for capture kernel. In that case crashk_res will
be
> 
> > zero for start and end and you don't want to trim down the
> functionality
> > of your driver.
> > 
> > > 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.
> > > 
> > 
> > 20MB is huge. I agree that it is a good idea to bring it down for
> > capture
> > kernel if performance is not significantly impacted.
> > 
> > > 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.
> > > 
> > 
> > Makes sense.
> > 
> > Thanks
> > Vivek

---
~Randy