Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices

Eric W. Biederman (ebiederm@xmission.com)
13 Oct 2002 17:49:09 -0600


O.k. After having been away from active development on the kernel
for a while I have now reviewed what you are seeing and I have a much
firmer grasp of what is going on.

The change that merged device_shutdown and device_suspend was buggy.
There really should have been a second state added so no behaviour
would change. This does not affect the reboot case, but it does
affect the other users of SUSPEND_POWER_DOWN which does request
devices be powered off. Which is noticeably from what you want in
device_shutdown() which is the preparation for reboot/halt.

The change that went into 2.5.42 was the behavior of the ide
driver changed. device_shutdown has always called device->remove,
and it has been in the reboot path for a very long time. The ide
driver just implemented a remove method, replacing it's reboot
notifier, and in that change the ide driver started spinning down disk
on reboot as well as shutdown. So please talk to the author of the
ide change if you do not like the current ide behaviour.

machine_restart returns control to the BIOS.
It works this way on both x86 and alpha. And the BIOS does
not always toggle the RESET line on the machine. The frequent case
of devices not working in Linux after rebooting from windows, and
visa versa is evidence of this. On alpha the SRM doesn't even
pretend to reset the machine.

Therefore the reboot code needs to put devices in a sane state, and
given the general perversity of hardware and that there is not a
defined way to do this generically except resetting the pci bus
the device drivers need to be involved. A reboot notifier is an ugly
way to do this, and walking the power management tree is a much
cleaner way to accomplish this. Additionally it was decided quite a
while ago that calling device->remove() was the correct way to
accomplish this.

Reboot problems show up more clearly when booting linux from linux but
that just makes it more explicit. It does not introduce any new
potentials for problems, in this area.

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/