lkml.org 
[lkml]   [2005]   [Apr]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] PCI: Add pci shutdown ability
    From
    Date
    On Mon, 2005-04-25 at 14:58 -0700, Andrew Morton wrote:
    > 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.

    That i bogus, USB will never stop DMA unless told to do so for example.

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

    Ok, good. So kdump don't need to call PMSG_FREEZE, normal kexec still
    does though.

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

    Yup.

    > 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.
    >
    > -
    > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    > the body of a message to majordomo@vger.kernel.org
    > More majordomo info at http://vger.kernel.org/majordomo-info.html
    > Please read the FAQ at http://www.tux.org/lkml/
    --
    Benjamin Herrenschmidt <benh@kernel.crashing.org>

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-04-26 05:52    [W:0.023 / U:1.704 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site