Re: [PATCH] PCI: Add pci shutdown ability

Benjamin Herrenschmidt
2005-04-26T03:47:05Z

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>