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 ?)
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.
3) if there's a way to just reset some or all devices on the
PCI bus without knowing what they are, this should have the
desired effect, while being relatively easy to implement.
(This probably still leaves things like AGP, multi-level PCI
bus structures, non-PCI, etc.)
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - 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