Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 20 Nov 2002 11:43:40 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 20 Nov 2002 11:43:40 -0500 Received: from ebiederm.dsl.xmission.com ([166.70.28.69]:28503 "EHLO frodo.biederman.org") by vger.kernel.org with ESMTP id ; Wed, 20 Nov 2002 11:43:39 -0500 To: Werner Almesberger Cc: suparna@in.ibm.com, Andy Pfiffer , Linux Kernel Mailing List , Linus Torvalds , Alan Cox , "Matt D. Robinson" , Rusty Russell , Mike Galbraith , "Martin J. Bligh" , Dave Hansen Subject: Re: [ANNOUNCE][CFT] kexec for v2.5.48 && kexec-tools-1.7 -- Success Story! References: <1037055149.13304.47.camel@andyp> <1037148514.13280.97.camel@andyp>

<1037668241.10400.48.camel@andyp> <20021120141925.A2524@in.ibm.com> <20021120120551.O17062@almesberger.net> From: ebiederm@xmission.com (Eric W. Biederman) Date: 20 Nov 2002 09:48:29 -0700 In-Reply-To: <20021120120551.O17062@almesberger.net> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 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: 1956 Lines: 39 Werner Almesberger writes: > Eric W. Biederman wrote: > > The needed hooks are there. You can make certain an appropriate > > ->shutdown()/reboot_notifier method is present, or you can fix the driver > > so it can initialize the device from any random state. > > In the case of a crash, you may not be able to use the normal > shutdown, but there may still be pending bus master accesses, e.g. > from an on-going transfer, or free buffers that will eventually > (i.e. there's no use in "waiting for the operation to finish") get > used. > > Initializing the device from any state is certainly a good feature, > and it will cure the most visible symptoms, but problems may still > occur if the device decides to scribble over memory after leaving > the original kernel, and before the reset has occurred under the > new kernel. (Or did you mean to initialize before invoking kexec ? In this case I suspect the best route is to locate the kexec_on_panic buffers for kexec where we want to use them. Then even in most cases a devices is scribbling on memory, unless the device was improperly setup, it isn't scribbling on memory necessary to get the new kernel going. > I see several possible approaches for this: > > 0) do as bootimg did, and ignore the problem :-) > 1) try to call the regular device shutdown. In the case of a > crash, this may hang, or corrupt the system further. > 2) add a new callback that just silences the device, without > trying to clean things up. This is probably the best > long-term solution. Roughly that is ->shutdown() it was separated from the ->remove() case so that it could be stripped down to a minimal implementation. Eric - 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/