kdump info request

Mon Oct 1 12:31:45 EDT 2007

On Mon, 1 Oct 2007 09:35:04 -0600 Mukker, Atul wrote:

> 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

I'm not the right person to answer that, but going forward, it would
be nice to have that information and it would be good to do correctly.

I think that scanning <saved_command_line> is not actually the good/right
way to do this.  It should just be a flag somewhere, and the flag should
be available in all (future) kernels (and likely easily backportable
as well, if that matters), meaning those built without kdump support.

But it's still up to the kexec developers...

> -----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