Re: kdump info request

[Vivek Goyal <vgoyal@in.ibm.com>]

On Mon, Oct 01, 2007 at 09:31:45AM -0700, Randy Dunlap wrote:
> 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...
> 
> 

Hi Atul/Randy,

[CCing to LKML]

Thinking more about it, looks like scanning command line is not a very good
idea.

I think we should instead look for if total available RAM in the system and
then let driver make a decision about how much memory to allocate. Pavel
already suggested it on LKML and I like the idea.

This is more generic and can be applied to kdump, kexec based hibernation and
all the future users of kexec on panic infrstrcuture which will boot a 
second kernel in restricted amount of RAM.

I am not sure what's the best way to determine the total RAM in the system
in arch independent manner. Some VM guys can tell it better. One of the ways
could be to parse /proc/iomem, the way kexec-tools does. Balbir mentioned
that traverse through the nodes and sum up present_pages. 

Any suggestions, what's the best way to determine total amount of RAM
in the system in kernel?

Right now this seems to be one odd case so this code can be inside module.
If there are more users of it then we can probably create a flag inside
kernel and export it.

Thanks
Vivek
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/