[lkml]   [2005]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.
Itsuro Oda <> writes:

> Hi,
> On 03 Feb 2005 02:00:51 -0700
> (Eric W. Biederman) wrote:
> > > 5) dump kernel: export all valid physical memory (and saved register
> > > information) to the user. (as /dev/oldmem /proc/vmcore ?)
> >
> > Or in user space, by just mmaping /dev/mem. That is part of the
> > current conversation. The only real point for putting that code in
> > the kernel (besides momentum) is it is a cheap way to get the exact
> > data structures of the kernel you are using. But since:
> > (a) it does not look like any primary kernel data structures need to
> > be examined.
> > (b) even simple compile options like SMP/NOSMP are enough to change
> > the layout of the data structures.
> > I think there is a pretty good case for moving all of the work to
> > user space. But you still need a kernel that loads and
> > runs in the reserved area.
> >
> I don't make sense. what do you mean ?
> What we want to do when the system is crashed is storing the whole
> physical memory (and saved register information for x86 arch) to
> some place (ex. a disk partition) for later analysis.
> So the basic requirments to the dump kernel is that:
> * supply a method to access whole (valid) physical memory.
> * supply a method to access the saved register information.
> Does the kdump meet this requirment ?

Yes, the discussion in this area is what is the best way to implement
this requirement. How much should be in the kernel and how much
should be in user space.

At the moment things are broken but should be fixed shortly.
So what has been implemented are /dev/oldmem which provides access
to the old memory. And /proc/vmcore which provides both the old
memory and the register information.

> (I am not interesting to /proc/vmcore. Constructing the vmcore
> image is area of analysis tools. not kernel's task.)

There is a fine line there, as a simple ELF core dump has just enough
information to describe discontiguous memory, and to have an out of
band channel for register information. Adding anything extra like
virtual addresses that match the kernel should be left for the
crash dump analysis tools.

In code that is currently in the mainstream kernel /dev/mem can
mmap any area of memory that is not used by the kernel as ram.
So what I believe we will end up is that /sbin/kexec (user space)
will prepare an ELF header (data) that describes the memory regions
and details where to find the kernels register information. The
address of that ELF header will be passed to the crash dump
capture kernel and user space combination. The something
(probably a user space program reading /dev/mem) will look
at the ELF header and save the already prepared ELF core
dump to disk. Possibly doing little things like merging
the MAX_NR_CPUS note segments into one so it actually conforms
to the ELF spec.

This thread started as the design discussion before finishing
that part of the implementation. The proof of concept
implementations have happened. We have all seen this kind
of functionality implemented. Now is the time to come up
with a good solid design that can be maintained and merged
into the mainline kernel and distros.

So thank you for ask questions, it means we have a better chance
of getting a solid design and a design that those people who
care about this functionality can use. And with a little luck
we can all wind up on agreeing on the general principles. You came in
a little late to this conversation so a lot of details have been
settled, but if you have a good argument for doing something another
way we can certainly look at that.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.141 / U:2.736 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site