Re: Determine version of kernel that produced vmcore

["Ken'ichi Ohmichi" <oomichi@mxs.nes.nec.co.jp>]

Hi Dave,

2007/07/23 17:08:22 -0400, Dave Anderson <anderson@redhat.com> wrote:
> > From: "Ken'ichi Ohmichi" <oomichi@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

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