linux/arch/x86/kernel/reboot_64.c

192 lines
3.5 KiB
C
Raw Normal View History

/* Various gunk just to reboot the machine. */
#include <linux/module.h>
#include <linux/reboot.h>
#include <linux/init.h>
#include <linux/smp.h>
#include <linux/kernel.h>
#include <linux/ctype.h>
#include <linux/string.h>
[PATCH] i386/x86-64: Don't IPI to offline cpus on shutdown 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>
2006-01-11 21:43:12 +00:00
#include <linux/pm.h>
#include <linux/kdebug.h>
#include <linux/sched.h>
#include <linux/efi.h>
#include <acpi/reboot.h>
#include <asm/io.h>
#include <asm/delay.h>
#include <asm/desc.h>
#include <asm/hw_irq.h>
#include <asm/system.h>
#include <asm/pgtable.h>
#include <asm/tlbflush.h>
#include <asm/apic.h>
#include <asm/hpet.h>
#include <asm/gart.h>
/*
* Power off function, if any
*/
void (*pm_power_off)(void);
EXPORT_SYMBOL(pm_power_off);
static long no_idt[3];
enum reboot_type reboot_type = BOOT_KBD;
static int reboot_mode = 0;
int reboot_force;
/* reboot=t[riple] | k[bd] | e[fi] [, [w]arm | [c]old]
warm Don't set the cold reboot flag
cold Set the cold reboot flag
triple Force a triple fault (init)
kbd Use the keyboard controller. cold reset (default)
acpi Use the RESET_REG in the FADT
efi Use efi reset_system runtime service
force Avoid anything that could hang.
*/
static int __init reboot_setup(char *str)
{
for (;;) {
switch (*str) {
case 'w':
reboot_mode = 0x1234;
break;
case 'c':
reboot_mode = 0;
break;
case 't':
case 'a':
case 'b':
case 'k':
case 'e':
reboot_type = *str;
break;
case 'f':
reboot_force = 1;
break;
}
if((str = strchr(str,',')) != NULL)
str++;
else
break;
}
return 1;
}
__setup("reboot=", reboot_setup);
static inline void kb_wait(void)
{
int i;
for (i=0; i<0x10000; i++)
if ((inb_p(0x64) & 0x02) == 0)
break;
}
void machine_shutdown(void)
{
unsigned long flags;
/* Stop the cpus and apics */
#ifdef CONFIG_SMP
int reboot_cpu_id;
/* The boot cpu is always logical cpu 0 */
reboot_cpu_id = 0;
/* Make certain the cpu I'm about to reboot on is online */
if (!cpu_isset(reboot_cpu_id, cpu_online_map)) {
reboot_cpu_id = smp_processor_id();
}
/* Make certain I only run on the appropriate processor */
set_cpus_allowed(current, cpumask_of_cpu(reboot_cpu_id));
/* O.K Now that I'm on the appropriate processor,
* stop all of the others.
*/
smp_send_stop();
#endif
local_irq_save(flags);
#ifndef CONFIG_SMP
disable_local_APIC();
#endif
disable_IO_APIC();
#ifdef CONFIG_HPET_TIMER
hpet_disable();
#endif
local_irq_restore(flags);
pci_iommu_shutdown();
}
void machine_emergency_restart(void)
{
int i;
/* Tell the BIOS if we want cold or warm reboot */
*((unsigned short *)__va(0x472)) = reboot_mode;
for (;;) {
/* Could also try the reset bit in the Hammer NB */
switch (reboot_type) {
case BOOT_KBD:
for (i=0; i<10; i++) {
kb_wait();
udelay(50);
outb(0xfe,0x64); /* pulse reset low */
udelay(50);
}
case BOOT_TRIPLE:
load_idt((const struct desc_ptr *)&no_idt);
__asm__ __volatile__("int3");
reboot_type = BOOT_KBD;
break;
case BOOT_ACPI:
acpi_reboot();
reboot_type = BOOT_KBD;
break;
case BOOT_EFI:
if (efi_enabled)
efi.reset_system(reboot_mode ? EFI_RESET_WARM : EFI_RESET_COLD,
EFI_SUCCESS, 0, NULL);
reboot_type = BOOT_KBD;
break;
}
}
}
void machine_restart(char * __unused)
{
printk("machine restart\n");
if (!reboot_force) {
machine_shutdown();
}
machine_emergency_restart();
}
void machine_halt(void)
{
}
void machine_power_off(void)
{
[PATCH] i386/x86-64: Don't IPI to offline cpus on shutdown 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>
2006-01-11 21:43:12 +00:00
if (pm_power_off) {
if (!reboot_force) {
machine_shutdown();
}
pm_power_off();
[PATCH] i386/x86-64: Don't IPI to offline cpus on shutdown 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>
2006-01-11 21:43:12 +00:00
}
}