Bug#623177: linux-2.6: Please enable CONFIG_CRASH_DUMP on x86 architectures
On Sun, Jun 10, 2012 at 03:02:30PM +0100, Ben Hutchings wrote:
> On Sun, 2012-06-10 at 00:44 -0700, John Wright wrote:
> > On Sat, Jun 02, 2012 at 07:02:11PM +0100, Ben Hutchings wrote:
> > > The help text for this option is:
> > >
> > > "Generate crash dump after being started by kexec.
> > > This should be normally only set in special crash dump kernels
> > > which are loaded in the main kernel with kexec-tools into
> > > a specially reserved region and then later executed after
> > > a crash by kdump/kexec. ..."
> > >
> > > Are you asking us to add a kdump flavour, as some other distributions
> > > do?
> >
> > It's not necessary to have another flavor. Kernels built with this
> > option work just fine as regular kernels too (in fact, the ia64 and
> > probably some other kernels are already built this way). As I recall,
> > as the kernel is currently built, it can be loaded as a crash kernel,
> > and kexec'ed successfully upon kernel panic; however, CONFIG_CRASH_DUMP
> > is required to enable /proc/vmcore in the newly booted kernel, which
> > contains the memory of the crashed kernel. Then, a tool like
> > 'makedumpfile' can read the core, stripping out user and zero pages, and
> > write a small dump file that can be analyzed with tools like 'crash'.
>
> The help text for CRASH_DUMP on x86 says:
>
> Generate crash dump after being started by kexec.
> This should be normally only set in special crash dump kernels
> ...
>
> Since this is not the only use for kexec, I don't believe we should
The documentation is misleading. It doesn't cause the kernel to
generate any dump; it just enables /proc/vmcore *if* the kernel is
kexec'ed as a result of the previous kernel panicking. Nothing special
(compared to other kernels) happens in a normal (not-triggered-by-panic)
kexec of a CONFIG_CRASH_DUMP=y kernel.
> enable this in the currently defined flavours (or that it should have
> been enabled for ia64).
>
> As I said, other distributions have a separate kdump flavour, presumably
> for this reason.
(Adding Troy, who might have more insight on the historic need for a
kdump kernel.)
The separate kdump flavors started mainly because some architectures
weren't relocatable, so it was impossible to use the same image for your
normal kernel and your crash kernel. That hasn't been the case for x86,
ia64, or ppc for quite some time. Also, the i386_defconfig and
x86_64_defconfig files upstream have had CONFIG_CRASH_DUMP=y since 2008:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=5cb04df8d3f03e37a19f2502591a84156be71772
The upstream kdump documentation talks about using the same kernel for
kdump as well:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/kdump/kdump.txt#l112
I think adding another flavor just for CONFIG_CRASH_DUMP is really
heavy-weight, especially given that upstream has enabled it by default
for four years, and it touches so few pieces of code.
--
John Wright <jsw@debian.org>
Reply to: