Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261572AbVDZPMO (ORCPT ); Tue, 26 Apr 2005 11:12:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261567AbVDZPMN (ORCPT ); Tue, 26 Apr 2005 11:12:13 -0400 Received: from iolanthe.rowland.org ([192.131.102.54]:3968 "HELO iolanthe.rowland.org") by vger.kernel.org with SMTP id S261572AbVDZPL5 (ORCPT ); Tue, 26 Apr 2005 11:11:57 -0400 Date: Tue, 26 Apr 2005 11:11:54 -0400 (EDT) From: Alan Stern X-X-Sender: stern@iolanthe.rowland.org To: Andrew Morton cc: alexn@dsv.su.se, , , , , , , Subject: Re: [PATCH] PCI: Add pci shutdown ability In-Reply-To: <20050425145831.48f27edb.akpm@osdl.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1807 Lines: 41 On Mon, 25 Apr 2005, Andrew Morton wrote: > 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. Like Pavel said, this won't work. > (Ongoing DMA is not a problem actually, because the kdump kernel won't be > using that memory anyway) For PCI devices at least, DMA _can_ be disabled in a uniform way as devices are discovered. Some platforms might not want to do this for fear it would kill the initial console display. IRQs _cannot_ be disabled in a uniform way. So they remain a problem. > 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 at some point you have to enable local IRQs, and then you're in trouble if a device without a driver is generating requests. Unless the new kernel can run with interrupts entirely disabled? Seems pretty unlikely. The real problem is that, in general, hardware _can't_ be reset properly by a new kernel. There are things that can help, like the PCI USB quirks code. That might be enough to handle the most pressing existing problems; certainly it would avoid the USB issues we've seen. (But it needs to be updated to avoid interfering with normal operations during resume-from-disk.) Alan Stern - 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/