From: Corey Minyard <minyard@acm.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Corey Minyard <cminyard@mvista.com>,
Werner Almesberger <wa@almesberger.net>,
Zwane Mwaikambo <zwane@holomorphy.com>,
suparna@in.ibm.com, Kenneth Sumrall <ken@mvista.com>,
linux-kernel@vger.kernel.org, lkcd-devel@lists.sourceforge.net
Subject: Re: Kexec, DMA, and SMP
Date: Sun, 16 Feb 2003 22:26:08 -0600 [thread overview]
Message-ID: <3E506460.3010400@acm.org> (raw)
In-Reply-To: <m1y94f6gnp.fsf@frodo.biederman.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eric W. Biederman wrote:
|Corey Minyard <minyard@acm.org> writes:
|
|
|
|>Eric W. Biederman wrote:
|>
|>|Corey Minyard <cminyard@mvista.com> writes:
|>|
|>|>|
|>|>|(So adding a special mode to the power management code may
|>|>|be too much overhead. Besides, sometimes, you can just pull
|>|>|a reset line, and don't have to do anything even remotely
|>|>|related to power management.)
|>|>
|>|>True, I didn't mean the high-level power management code directly.
But the
|>|>PCI API defines a suspend operation that could take a special mode
for this.
|>|
|>|
|>|The generic device api has a shutdown method for this. And in the
non panic
|>|case we use it. Not a lot of devices have it implemented but it exists.
|>|
|>|And except that it doesn't have a restriction that it can't block is
pretty
|>|much what you want.
|>
|>That's a pretty big restriction. Plus, you can't claim spinlocks.
|>
|>The panic shutdown is different from an orderly shutdown. What the
current
|>shutdown does is probably not what you want.
|>
|>
|
|I do not see a large difference between the desired semantics of an
|orderly shutdown, and the desired semantics of a panic shutdown.
|
An orderly shutdown will:
~ * claim locks and block as necessary
~ * free memory associated with the device
~ * flush device queues
~ * Fully shut down the device
An orderly shutdown should make sure the system remains sane after it
finishes and the data on the device is correct.
A panic shutdown should only disable DMA with as little code as possible
without locking, blocking, etc. No effort should be taken to keep the
system sane (beyond clobbering memory), since it's not sane to begin
with :-).
You may want to say that this shutdown will be the panic shutdown and not be
an orderly shutdown. That's fine, although I would suggest a name change.
I couldn't find any documentation on what the shutdown call was supposed
to do.
|
|
|
|Because the kernel to handle the panic only initializes those devices
|it can reliably initialize from any state. And it is living in an
|area of memory the old kernel did not allow DMA to.
|
Are you sure this will be ok? I'm not sure either way. How much memory
does
a kernel take to boot up and operate for this? If it's a few meg, it's
probably livable.
If it's a lot of memory, it's probably not going to be acceptable.
Plus, perhaps you would want to protect the output of the kernel dump
somehow.
That's going to be a lot more memory than you can reserve. And if you
can shut
off DMA, none of this should matter anyway.
The rest of what you said, about the panic kernel only taking the core
dump and
then rebooting, makes sense to me.
- -Corey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE+UGRfIXnXXONXERcRArgvAJ96cqVaxZeA83KuR1kSXFKVRSnpIACfQ83W
gc5bibmlh4sPmmq6onPc5w0=
=bgpj
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2003-02-17 4:16 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3E448745.9040707@mvista.com>
[not found] ` <m1isvuzjj2.fsf@frodo.biederman.org>
2003-02-08 20:18 ` Kexec, DMA, and SMP Corey Minyard
2003-02-09 18:39 ` Eric W. Biederman
2003-02-10 11:14 ` Kexec on 2.5.59 problems ? Suparna Bhattacharya
2003-02-10 17:09 ` [Fastboot] " Andy Pfiffer
2003-02-10 18:07 ` Eric W. Biederman
2003-02-11 7:21 ` Suparna Bhattacharya
2003-02-11 17:04 ` Andy Pfiffer
2003-02-11 23:46 ` Andy Pfiffer
2003-02-12 4:29 ` Eric W. Biederman
2003-02-12 22:31 ` Andy Pfiffer
2003-02-13 9:50 ` Suparna Bhattacharya
2003-02-13 15:10 ` Eric W. Biederman
2003-02-18 10:59 ` Suparna Bhattacharya
2003-02-18 15:06 ` Eric W. Biederman
2003-02-10 12:12 ` Kexec, DMA, and SMP Suparna Bhattacharya
2003-02-10 13:56 ` Corey Minyard
2003-02-10 15:07 ` Suparna Bhattacharya
2003-02-10 15:22 ` Corey Minyard
2003-02-10 17:56 ` Eric W. Biederman
2003-02-11 1:35 ` Kenneth Sumrall
2003-02-11 5:08 ` Eric W. Biederman
2003-02-11 17:09 ` Stephen Hemminger
2003-02-11 12:55 ` Suparna Bhattacharya
2003-02-11 13:40 ` Suparna Bhattacharya
2003-02-11 14:06 ` Corey Minyard
2003-02-11 14:40 ` Suparna Bhattacharya
2003-02-11 15:20 ` Corey Minyard
2003-02-12 4:28 ` Eric W. Biederman
2003-02-12 14:17 ` Corey Minyard
2003-02-12 14:51 ` Eric W. Biederman
2003-02-12 16:06 ` Corey Minyard
2003-02-13 11:13 ` Suparna Bhattacharya
2003-02-14 3:13 ` Werner Almesberger
2003-02-14 14:20 ` Corey Minyard
2003-02-14 18:10 ` Werner Almesberger
2003-02-14 18:23 ` Corey Minyard
2003-02-14 19:26 ` Zwane Mwaikambo
2003-02-14 19:44 ` Werner Almesberger
2003-02-14 20:00 ` Corey Minyard
2003-02-15 6:03 ` Eric W. Biederman
2003-02-16 16:22 ` Corey Minyard
2003-02-16 21:48 ` Eric W. Biederman
2003-02-17 4:26 ` Corey Minyard [this message]
2003-02-17 7:18 ` Eric W. Biederman
2003-02-17 17:32 ` Corey Minyard
2003-02-12 4:47 ` Suparna Bhattacharya
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=3E506460.3010400@acm.org \
--to=minyard@acm.org \
--cc=cminyard@mvista.com \
--cc=ebiederm@xmission.com \
--cc=ken@mvista.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkcd-devel@lists.sourceforge.net \
--cc=suparna@in.ibm.com \
--cc=wa@almesberger.net \
--cc=zwane@holomorphy.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