On Fri, 2005-01-21 at 13:24, Eric W. Biederman wrote: > Vivek Goyal <[EMAIL PROTECTED]> writes: > > > Hi Andrew, > > > > Following patch is against 2.6.11-rc1-mm2. > > > > As mentioned by following note from Eric, crashdump code is currently > > broken. > > > > > > The crashdump code is currently slightly broken. I have attempted to > > > minimize the breakage so things can quick be made to work again. > > > > We have started doing changes to make crashdump up and running again. > > Following are few identified items to be done. > > > > 1. Reserve the backup region (640k) during kernel bootup. > > Why do we need a separate region for this? > > It should be simple enough to take 640 out of the area kexec reserves > for the crash dump kernel. That is what the previous code implemented.
Previous code also reserved the backup memory region after crash kernel region. It is just a matter of interpretation. What I understand that crash kernel reserved region represents something where one can load the panic kernel directly and new kernel can use this memory region for memory allocation. I don't want to steal the backup region from crash kernel region otherwise, I shall have to boot the crash kernel with some strange values like memmap=(32M-640k)@16M (symbolically) to prevent crash kernel overwriting backup region. Why to make user aware of location of backup region. Alternatively, this can be managed by reserving this backup region again in crash kernel to avoid any stomping. May be pass backup region location to new kernel through parameter segment or through command line but don't see a strong reason for doing that. Thanks Vivek - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/