Re: [PATCH] PCI: Add pci shutdown ability

[Benjamin Herrenschmidt]

On Mon, 2005-04-25 at 14:58 -0700, Andrew Morton wrote:
> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-- 
Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>

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