Messages in this thread | | | Subject | Re: [ANNOUNCE][CFT] kexec for v2.5.48 && kexec-tools-1.7 -- Success Story! | From | (Eric W. Biederman) | Date | 20 Nov 2002 09:48:29 -0700 |
| |
Werner Almesberger <wa@almesberger.net> 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/
| |