mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: alexn@dsv.su.se, greg@kroah.com, gud@eth.net,
	linux-kernel@vger.kernel.org, linux-pci@atrey.karlin.mff.cuni.cz,
	jgarzik@pobox.com, cramerj@intel.com,
	linux-usb-devel@lists.sourceforge.net
Subject: Re: [PATCH] PCI: Add pci shutdown ability
Date: Mon, 25 Apr 2005 14:58:31 -0700	[thread overview]
Message-ID: <20050425145831.48f27edb.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0504251609420.7408-100000@iolanthe.rowland.org>

Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Mon, 25 Apr 2005, Alexander Nyberg wrote:
> 
> > Not sure what you mean by "make kexec work nicer" but if it is because
> > some devices don't work after a kexec I have some objections.
> 
> That was indeed the reason, at least in my case.  The newly-rebooted
> kernel doesn't work too well when there are active devices, with no driver
> loaded, doing DMA and issuing IRQs because they were never shut down.

I have vague memories of this being discussed at some length last year. 
Nothing comprehensive came of it, except that perhaps the kdump code should
spin with irqs off for a couple of seconds so the DMA and IRQs stop.

(Ongoing DMA is not a problem actually, because the kdump kernel won't be
using that memory anyway)

> > What about the kexec-on-panic?
> > 
> > In the end at least every storage device should work after a
> > kexec-on-panic or else there might be cases where we cannot get dumps of
> > what happened. My guess is that having access to the network might come
> > in handy after a kexec-on-panic as well.
> > 
> > So if this patch is because some devices don't work across kexec I don't
> > think this is a good idea because the same devices won't work after a
> > kexec-on-panic.
> 
> Do I understand your argument correctly?  You seem to be saying that 
> because this new facility sometimes won't work (the kexec-on-panic case) 
> it shouldn't be added at all.  What about all the other times when it will 
> work?

For kdump we really don't want to be doing fancy driver shutdown inside a
crashed kernel.  It would be better to just jump to the new kernel and
to reset the hardware from there.  DMA doesn't matter, and maybe IRQs can
be handled with a sustained local_irq_disable() (hard).

But for the normal kexec path, yes, graceful device shutdown is desirable.

So the requirements for the two different kexec scenarios are quite
different and it seems unlikely that any single approach to device shutdown
will suit both situations.


  parent reply	other threads:[~2005-04-25 22:03 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.LNX.4.44L0.0504251128070.5751-100000@iolanthe.rowland.org>
     [not found] ` <20050425182951.GA23209@kroah.com>
     [not found]   ` <SVLXCHCON1syWVLEFN00000099e@SVLXCHCON1.enterprise.veritas.com>
     [not found]     ` <20050425185113.GC23209@kroah.com>
2005-04-25 19:06       ` Greg KH
2005-04-25 19:23         ` Jeff Garzik
2005-04-25 20:07           ` Greg KH
2005-04-25 20:11           ` Adam Belay
2005-04-25 19:45         ` Alexander Nyberg
2005-04-25 20:12           ` Greg KH
2005-04-26  3:59             ` Benjamin Herrenschmidt
2005-04-25 20:14           ` Alan Stern
2005-04-25 20:52             ` Alexander Nyberg
2005-04-25 21:12               ` Alan Stern
2005-04-26 15:49                 ` Grant Grundler
2005-04-26 16:04                   ` Alan Stern
2005-04-26 16:37                     ` Grant Grundler
2005-04-26 17:14                       ` Alan Stern
2005-04-26 17:41                         ` Grant Grundler
2005-05-11  5:33                 ` Vivek Goyal
2005-05-11 14:38                   ` Alan Stern
2005-04-25 21:58             ` Andrew Morton [this message]
2005-04-25 22:13               ` Dave Jones
2005-04-25 23:23                 ` Adam Belay
2005-04-26  4:32                   ` Benjamin Herrenschmidt
2005-04-26  6:23                     ` Adam Belay
2005-04-26  7:14                       ` [linux-pm] " Nigel Cunningham
2005-04-26  9:16                       ` Pavel Machek
2005-04-26  9:41                   ` Pavel Machek
2005-04-26  3:52                 ` Benjamin Herrenschmidt
2005-04-26 15:14                   ` Alan Stern
2005-04-26  9:39                 ` Pavel Machek
2005-04-26 17:50                   ` Dave Jones
2005-04-26 20:23                     ` Pavel Machek
2005-04-26  3:45               ` Benjamin Herrenschmidt
2005-04-26 15:11               ` Alan Stern
2005-04-26 16:01                 ` Alexander Nyberg
2005-04-26 15:41             ` Grant Grundler
2005-04-26 16:07               ` Richard B. Johnson
2005-04-26 16:19                 ` Grant Grundler
2005-04-26 17:12                   ` Alan Stern
2005-04-26 17:19                     ` Lee Revell
2005-04-25 20:08         ` Adam Belay
2005-04-25 20:19           ` Greg KH
2005-04-25 20:24             ` Adam Belay
2005-04-25 20:42         ` Pavel Machek
2005-04-25 20:55           ` Adam Belay
2005-04-25 21:06             ` Pavel Machek
2005-04-26  4:30               ` Benjamin Herrenschmidt
2005-04-26 16:12                 ` Grant Grundler
2005-04-26 13:44               ` [linux-usb-devel] " David Brownell
2005-04-26 21:15                 ` Pavel Machek
2005-04-25 21:00           ` Greg KH
2005-04-25 21:13             ` Pavel Machek
2005-04-26  3:41             ` Benjamin Herrenschmidt
2005-04-26 10:11               ` Pavel Machek
2005-04-25 21:13           ` [linux-usb-devel] " David Brownell
2005-04-26  3:39           ` Benjamin Herrenschmidt
2005-04-26  6:33             ` Adam Belay
2005-04-26  6:44               ` Greg KH
2005-05-04  7:02 [PATCH] PCI: fix up word-aligned 16-bit PCI config access through sysfs Greg KH
2005-05-04  7:02 ` [PATCH] PCI: Add pci shutdown ability Greg KH

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=20050425145831.48f27edb.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=alexn@dsv.su.se \
    --cc=cramerj@intel.com \
    --cc=greg@kroah.com \
    --cc=gud@eth.net \
    --cc=jgarzik@pobox.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@atrey.karlin.mff.cuni.cz \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=stern@rowland.harvard.edu \
    /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®