Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API

[Eric W. Biederman]

Suparna Bhattacharya <suparna@xxxxxxxxxx> writes:

> This differs a little from your earlier suggestion of requiring
> a kernel to run from a non-default address. Martin suggested simply
> reserving about 16MB of area in advance, so that just before kexecing
> the new kernel with mem=16M, we save the first 16MB away into the
> reserved space. /dev/hmem (oldmem ?) is a view into the old kernel's
> memory, as opposed to /dev/mem.

Ok, That is fairly simple, and can be implemented easily, so it is
a good place to start.

A buffer to save old kernel state is needed.  At the very least
we need to save the old register state, copying over several megabytes
of data won't hurt the picture.

It has a little more exposure to on-going DMA transfers than running
from a reserved area of memory, as some of that memory may have been
setup as DMA buffers by the dying kernel. 

If it turns out that on-going DMA is a problem I see that as something
we can fix later on.


> > Does anyone have a proof of concept implementation?  I have been able to find
> 
> Yes, Hari has a nice POC implementation - it might make sense for him to post
> it rightaway for you to take a look. Basically, in addition to hmem (oldmem),
> the upcoming kernel exports an ELF core view of the saved register and memory 
> state of the previous kernel as /proc/vmcore.prev (remember your suggestion 
> of using an ELF core file format for dump ?), so one can use cp or scp to 
> save the core dump to disk. He has a quick demo, where he uses gdb (unmodified)
> to open the dump and show a stack trace of the dumping cpu.

Yes I would like to look at that.  

I am tempted to suggest the data buffer with the registers and memory
actually be in ELF format with virtual address representing where the
data was in memory, and the physical addresses reporting where the
data actually is in memory now.  Then we could just grab everything
with /dev/mem..

But I don't know how much of pain this would be.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/