Re: kexec Digest, Vol 4, Issue 28

Re: kexec Digest, Vol 4, Issue 28

[Dave Anderson]

> From: "Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>
> Subject: Re: Determine version of kernel that produced vmcore
...
> 
> 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...)

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.

Dave


> 
> Thanks
> Ken'ichi Ohmichi




_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec