All of lore.kernel.org
 help / color / mirror / Atom feed
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 10:22:40 -0600	[thread overview]
Message-ID: <3E4FBAD0.4040808@acm.org> (raw)
In-Reply-To: <m17kc26pxs.fsf@frodo.biederman.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

|
|>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...

The API is not done for panics.  There's no call that has the proper 
semantics.

|
|
|We just don't trust the dying kernel enough to use it during a panic.

I don't understand this.  If you can't trust a dying kernel to properly 
shut down devices, how can you trust it to boot a new kernel?  And (much 
worse) if you don't shut down the devices, how can you trust the new 
kernel to execute properly?  I know there are levels of trust here, but 
I'd much rather have the kernel lockup during the reboot than have a 
chance of a new kernel booting that could behave incorrectly.  In 
general, the chance of behaving incorrectly is MUCH worse than a sure 
lockup, especially in systems that must be reliable.

- -Corey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+T7rOIXnXXONXERcRAksfAJ9kVRD2S9OK5siBqAPMkbfi2iS2fgCeM3hw
Fjp2LXiNEURU+HNrByOGVBQ=
=5sxh
-----END PGP SIGNATURE-----



  reply	other threads:[~2003-02-16 16:12 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 [this message]
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=3E4FBAD0.4040808@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 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.