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/
This archive was generated by hypermail 2b29 : Sat Nov 23 2002 - 22:00:32 EST