From: Andrew Morton <akpm@osdl.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: ebiederm@xmission.com, suparna@in.ibm.com, fastboot@osdl.org,
mbligh@aracnet.com, linux-kernel@vger.kernel.org,
jbarnes@engr.sgi.com
Subject: Re: [Fastboot] Re: Announce: dumpfs v0.01 - common RAS output API
Date: Wed, 28 Jul 2004 15:42:30 -0700 [thread overview]
Message-ID: <20040728154230.11d658af.akpm@osdl.org> (raw)
In-Reply-To: <1091044742.31698.3.camel@localhost.localdomain>
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> On Mer, 2004-07-28 at 21:33, Andrew Morton wrote:
> > We really don't want to be calling driver shutdown functions from a crashed
> > kernel.
>
> Then at the very least you need to disable bus mastering and have
> specialist recovery functions for problematic devices. The bus
> mastering one is essential otherwise bus masters will continue to
> DMA random data into your new universe.
But they're welcome to do that: the memory for the DMA transfer has
already been allocated and our new universe will not be touching it.
What we need to do is to ensure that the new kexec-ed kernel appropriately
whacks the devices to stop any in-progress operations. So it's the probe() and
open() routines which need to get the device into a sane state, not the shutdown
routines.
This way:
- We have less devices to take care of: we only care about those devices
which are needed for a successful dump.
- We are poking at these devices in a known-good kernel, not from within
a kernel which has wrecked itself.
- Any devices which are performing DMA to/from the old kernel's memory
can just keep on doing that. The new kernel doesn't care, unless it
needs those devices for dumping.
next prev parent reply other threads:[~2004-07-28 22:52 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-22 16:19 Announce: dumpfs v0.01 - common RAS output API 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
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 [this message]
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-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=20040728154230.11d658af.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=ebiederm@xmission.com \
--cc=fastboot@osdl.org \
--cc=jbarnes@engr.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.