From: ebiederm@xmission.com (Eric W. Biederman)
To: Corey Minyard <cminyard@mvista.com>
Cc: 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: 14 Feb 2003 23:03:27 -0700 [thread overview]
Message-ID: <m17kc26pxs.fsf@frodo.biederman.org> (raw)
In-Reply-To: <3E4D4ADF.3070109@mvista.com>
Corey Minyard <cminyard@mvista.com> writes:
> Werner Almesberger wrote:
>
> |Zwane Mwaikambo wrote:
> |
> |>I don't think suspending devices is safe at that stage since removing
> |>devices and walking lists and freeing memory and disabling devices and...
> |>kicks up quite a storm.
> |
> |
> |If you *really* don't want to stop devices, you can use the
> |"reserved, non-DMA memory" approach, kexec the kernel that
> |records the crash dump, and then do a system-wide reset, or
> |such.
> |
> |But if you don't have that - possibly considerable - amount
> |of memory to spare, you don't have much of a choice than to
> |stop devices. Of course, crash dumps don't need a neat and
> |clean shutdown, so you can avoid all the kfrees, and such.
> |
> |(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.
> Or maybe a new field in the PCI structure (and equivalent for other things, if
> there are any). But the suspend and resume operations should at least give
> a good idea where its needed and how to use it.
The API is already done...
We just don't trust the dying kernel enough to use it during a panic.
Eric
next prev parent reply other threads:[~2003-02-15 5:53 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 [this message]
2003-02-16 16:22 ` Corey Minyard
2003-02-16 21:48 ` Eric W. Biederman
2003-02-17 4:26 ` Corey Minyard
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=m17kc26pxs.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=cminyard@mvista.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 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.