On Mon, 2005-04-25 at 14:58 -0700, Andrew Morton wrote: > Alan Stern <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- Benjamin Herrenschmidt <[EMAIL PROTECTED]> ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ [email protected] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
