Hi Mahesh, Thank you for quick response. On Fri, 15 Jul 2011 12:40:29 +0530 Mahesh J Salgaonkar <mahesh at linux.vnet.ibm.com> wrote: > > > > > > The current approach is to re-run the makedumpfile on the crash dump > > > (generated in the second kernel) when we are back into production kernel > > > (1st kernel). > > > > IIUC, there are be 2 dumpfiles on customer site by the above approach. > > The one is with privacy/secret data, and another is without. > > Correct. > > > > > If correct, I like this approach because a customer can have two options > > when the crash utility cannot read a dumpfile without privacy/secret data > > on support site. > > The crash utility would just display a warning message early on during > invocation. Most of the time crash tool will be able to read/analyze the > dump unless someone scrubs out the data on which crash utility is dependant > on. And as I mentioned previously, this is intended just as a security filter > and not to be used as detrimental to crash's analysis of the dump. I see, this feature will not be a problem in most cases. However a customer can create unreadable dumpfile by using this feature, and current makedumpfile does not have such feature. Of course unreadable dumpfile is due to wrong makedumpfile.conf, and I like this feature anyway because a customer has options. Thanks Ken'ichi Ohmichi > > First option: > > For digging a problem, a customer sends a dumpfile with privacy/secret > > data to support site. > > > > Second option: > > For protecting privacy/secret data, a customer gives up digging a problem.
