From: ebiederm@xmission.com (Eric W. Biederman)
To: Andrew Morton <akpm@osdl.org>
Cc: Keith Owens <kaos@sgi.com>,
linux-kernel@vger.kernel.org,
Suparna Bhattacharya <suparna@in.ibm.com>,
"Martin J. Bligh" <mbligh@aracnet.com>,
fastboot@osdl.org
Subject: Re: Announce: dumpfs v0.01 - common RAS output API
Date: 27 Jul 2004 19:53:01 -0600 [thread overview]
Message-ID: <m1r7qw7v9e.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20040725235705.57b804cc.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> Keith Owens <kaos@sgi.com> wrote:
> >
> > * How do we get a clean API to do polling mode I/O to disk?
>
> We hope to not have to. The current plan is to use kexec: at boot time, do
> a kexec preload of a small (16MB) kernel image. When the main kernel
> crashes or panics, jump to the kexec kernel. The kexec kernel will hold a
> new device driver for /dev/hmem through which applications running under
> the kexec'ed kernel can access the crashed kernel's memory.
Hmm. I think this will require one of the kernels to run at a
non-default address in physical memory.
> Write the contents of /dev/hmem to stable storage using whatever device
> drivers are in the kexeced kernel, then reboot into a real kernel
> again.
And at this point I don't quite see why you would need /dev/hmem,
as opposed to just using /dev/mem.
Or will the crashing kernel save and compress the core dump to
somewhere in ram and the dump kernel read it out from there?
> That's all pretty simple to do, and the quality of the platform's crash
> dump feature will depend only upon the quality of the platform's kexec
> support.
Which will largely depend on the quality of it's device drivers...
> People have bits and pieces of this already - I'd hope to see candidate
> patches within a few weeks. The main participants are rddunlap, suparna
> and mbligh.
I'm sorry I missed you then. Unfortunately this is my busiest season at work
so I wasn't able to make it to OLS this year :(
Does anyone have a proof of concept implementation? I have been able to find
a little bit of time for this kind of thing lately and have just done
the x86-64 port. (You can all give me a hard time about taking a year
to get back to it :) I am in the process of breaking everything up
into their individual change patches and doing a code review so I feel
comfortable with sending the code to Andrew. So this would be a very
good time for me to look at any code for reporting a crash dump with
a kernel started with kexec.
Eric
next prev parent reply other threads:[~2004-07-28 1:55 UTC|newest]
Thread overview: 60+ 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 [this message]
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
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
-- strict thread matches above, loose matches on Subject: below --
2004-07-22 15:42 Dan Kegel
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=m1r7qw7v9e.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=akpm@osdl.org \
--cc=fastboot@osdl.org \
--cc=kaos@sgi.com \
--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®