From: ebiederm@xmission.com (Eric W. Biederman)
To: suparna@in.ibm.com
Cc: Andrew Morton <akpm@osdl.org>,
fastboot@osdl.org, linux-kernel@vger.kernel.org,
"Martin J. Bligh" <mbligh@aracnet.com>
Subject: Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API
Date: 28 Jul 2004 09:12:25 -0600 [thread overview]
Message-ID: <m1k6wo17za.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20040728105455.GA11282@in.ibm.com>
Suparna Bhattacharya <suparna@in.ibm.com> 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
next prev parent reply other threads:[~2004-07-28 15:14 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-22 16:19 Keith Owens
2004-07-26 6:57 ` Andrew Morton
2004-07-28 1:53 ` Eric W. Biederman
2004-07-28 10:54 ` Suparna Bhattacharya
2004-07-28 10:46 ` [Fastboot] " Alan Cox
2004-07-28 14:38 ` Martin J. Bligh
2004-07-28 14:06 ` Alan Cox
2004-07-28 15:21 ` Martin J. Bligh
2004-07-28 15:56 ` Eric W. Biederman
2004-07-28 17:09 ` Andrea Arcangeli
2004-07-28 16:05 ` Eric W. Biederman
2004-07-28 15:42 ` Eric W. Biederman
2004-07-28 15:12 ` Eric W. Biederman [this message]
2004-07-28 15:23 ` Martin J. Bligh
2004-07-28 15:53 ` Eric W. Biederman
2004-07-28 16:03 ` Jesse Barnes
2004-07-28 18:00 ` Eric W. Biederman
2004-07-28 18:06 ` Jesse Barnes
2004-07-28 19:42 ` Martin J. Bligh
2004-07-28 19:56 ` [Fastboot] " Alan Cox
2004-07-28 19:44 ` Andrew Morton
2004-07-28 23:11 ` [Fastboot] " Eric W. Biederman
2004-07-28 22:53 ` Alan Cox
2004-07-29 1:12 ` Eric W. Biederman
2004-07-29 14:00 ` Alan Cox
2004-07-29 15:47 ` Eric W. Biederman
2004-07-28 18:21 ` Alan Cox
2004-07-28 19:23 ` Martin J. Bligh
2004-07-28 20:28 ` [Fastboot] " Eric W. Biederman
2004-07-28 20:33 ` Andrew Morton
2004-07-28 19:59 ` Alan Cox
2004-07-28 22:42 ` Andrew Morton
2004-07-28 22:44 ` Jesse Barnes
2004-07-28 23:17 ` Eric W. Biederman
2004-07-28 22:55 ` Alan Cox
2004-07-29 0:22 ` Andrew Morton
2004-07-29 13:57 ` Alan Cox
2004-07-29 18:17 ` Andrew Morton
2004-07-29 21:20 ` Alan Cox
2004-07-29 22:30 ` Gerrit Huizenga
2004-07-30 0:04 ` Eric W. Biederman
2004-07-29 23:25 ` Alan Cox
2004-07-30 4:07 ` Eric W. Biederman
2004-07-30 12:38 ` Gerrit Huizenga
2004-07-31 13:52 ` Matthias Urlichs
2004-07-30 15:24 ` Olivier Galibert
2004-07-29 1:05 ` Eric W. Biederman
2004-07-29 14:12 ` Martin J. Bligh
2004-07-28 23:44 ` Andrew Morton
2004-07-29 0:58 ` Eric W. Biederman
2004-07-29 1:09 ` Andrew Morton
2004-07-29 1:56 ` Eric W. Biederman
2004-07-29 14:18 ` Martin J. Bligh
2004-07-29 16:01 ` Eric W. Biederman
2004-07-29 16:19 ` Eric W. Biederman
2004-07-29 14:08 ` Martin J. Bligh
2004-07-29 15:52 ` Eric W. Biederman
2004-07-29 16:13 ` Martin J. Bligh
2004-07-29 17:12 ` Matthias Urlichs
2004-07-30 15:02 Manfred Spraul
2004-07-30 14:42 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1k6wo17za.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=fastboot@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@aracnet.com \
--cc=suparna@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®