Hi Dave, 2007/07/23 17:08:22 -0400, Dave Anderson <anderson at redhat.com> wrote: > > From: "Ken'ichi Ohmichi" <oomichi at mxs.nes.nec.co.jp> >... > > > > BTW, we should test makedumpfile by each linux(-rc1 ?) releases. > > Now, I test the makedumpfile functions by comparing the crash utility's > > output of /proc/vmcore and the one of the filtered dumpfile. > > Often, the crash utility cannot read /proc/vmcore of the latest kernel. > > Does anybody know the crash's option that the crash can run loosely for > > the early test ? > >There is no "loosely-run" option for the crash utility. > >When you state "cannot read /proc/vmcore", I'm presuming that >you mean that something fails during initialization due to >the "shifting sands" of the upstream kernel (and which should >be reported to the crash-utility list so that it can be >addressed...) As you said, I saw some problems that the crash utility failed during the initialization. I will report them to the crash-utility list if I find them. >There are a couple debug-only options that prevent crash from >accessing certain subsystems during initialization, such as >"--no_kmem_cache" to avoid traversing the kmalloc/slab subsystem, >and "--no_modules" to avoid traversing the vmalloc'd module list. >Those two may help if you have an "incomplete" dumpfile that is >missing pages that *should* be there. There's also a "-f" to >force the use of split vmlinux/vmlinux.debug pair whose CRC's >do not match. But if you're using a simple -g build vmlinux >files, that option wouldn't apply. Thank you for the information. I will use the above options until we update the crash utility. Thanks Ken'ichi Ohmichi
