forked from Minki/linux
6e3fbee5f1
So why are we calling smp_send_stop from machine_halt? We don't. Looking more closely at the bug report the problem here is that halt -p is called which triggers not a halt but an attempt to power off. machine_power_off calls machine_shutdown which calls smp_send_stop. If pm_power_off is set we should never make it out machine_power_off to the call of do_exit. So pm_power_off must not be set in this case. When pm_power_off is not set we expect machine_power_off to devolve into machine_halt. So how do we fix this? Playing too much with smp_send_stop is dangerous because it must also be safe to be called from panic. It looks like the obviously correct fix is to only call machine_shutdown when pm_power_off is defined. Doing that will make Andi's assumption about not scheduling true and generally simplify what must be supported. This turns machine_power_off into a noop like machine_halt when pm_power_off is not defined. If the expected behavior is that sys_reboot(LINUX_REBOOT_CMD_POWER_OFF) becomes sys_reboot(LINUX_REBOOT_CMD_HALT) if pm_power_off is NULL this is not quite a comprehensive fix as we pass a different parameter to the reboot notifier and we set system_state to a different value before calling device_shutdown(). Unfortunately any fix more comprehensive I can think of is not obviously correct. The core problem is that there is no architecture independent way to detect if machine_power will become a noop, without calling it. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org> |
||
|---|---|---|
| .. | ||
| alpha | ||
| arm | ||
| arm26 | ||
| cris | ||
| frv | ||
| h8300 | ||
| i386 | ||
| ia64 | ||
| m32r | ||
| m68k | ||
| m68knommu | ||
| mips | ||
| parisc | ||
| powerpc | ||
| ppc | ||
| s390 | ||
| sh | ||
| sh64 | ||
| sparc | ||
| sparc64 | ||
| um | ||
| v850 | ||
| x86_64 | ||
| xtensa | ||