License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
2012-05-22 02:50:07 +00:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2016-07-14 00:18:56 +00:00
|
|
|
#include <linux/export.h>
|
2006-12-07 04:40:06 +00:00
|
|
|
#include <linux/reboot.h>
|
2008-01-30 12:32:51 +00:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/pm.h>
|
|
|
|
#include <linux/efi.h>
|
2009-08-03 12:47:32 +00:00
|
|
|
#include <linux/dmi.h>
|
2009-10-07 13:09:06 +00:00
|
|
|
#include <linux/sched.h>
|
2009-09-02 01:25:07 +00:00
|
|
|
#include <linux/tboot.h>
|
2011-03-25 14:20:14 +00:00
|
|
|
#include <linux/delay.h>
|
2020-09-04 15:30:25 +00:00
|
|
|
#include <linux/objtool.h>
|
2020-06-09 04:32:42 +00:00
|
|
|
#include <linux/pgtable.h>
|
2008-01-30 12:32:51 +00:00
|
|
|
#include <acpi/reboot.h>
|
|
|
|
#include <asm/io.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <asm/apic.h>
|
2014-10-27 08:12:04 +00:00
|
|
|
#include <asm/io_apic.h>
|
2005-09-03 22:56:38 +00:00
|
|
|
#include <asm/desc.h>
|
2008-01-30 12:32:51 +00:00
|
|
|
#include <asm/hpet.h>
|
2008-04-27 23:15:59 +00:00
|
|
|
#include <asm/proto.h>
|
2007-05-02 17:27:06 +00:00
|
|
|
#include <asm/reboot_fixups.h>
|
2007-05-02 17:27:11 +00:00
|
|
|
#include <asm/reboot.h>
|
2008-12-27 13:02:28 +00:00
|
|
|
#include <asm/pci_x86.h>
|
2008-11-17 21:03:24 +00:00
|
|
|
#include <asm/virtext.h>
|
2009-01-07 16:05:48 +00:00
|
|
|
#include <asm/cpu.h>
|
2011-01-06 21:18:50 +00:00
|
|
|
#include <asm/nmi.h>
|
2012-06-17 04:47:37 +00:00
|
|
|
#include <asm/smp.h>
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-06-17 04:47:37 +00:00
|
|
|
#include <linux/ctype.h>
|
|
|
|
#include <linux/mc146818rtc.h>
|
|
|
|
#include <asm/realmode.h>
|
|
|
|
#include <asm/x86_init.h>
|
2014-06-13 11:39:55 +00:00
|
|
|
#include <asm/efi.h>
|
2008-01-30 12:32:51 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Power off function, if any
|
|
|
|
*/
|
|
|
|
void (*pm_power_off)(void);
|
2005-06-23 07:08:33 +00:00
|
|
|
EXPORT_SYMBOL(pm_power_off);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/*
|
|
|
|
* This is set if we need to go through the 'emergency' path.
|
2008-11-17 21:03:24 +00:00
|
|
|
* When machine_emergency_restart() is called, we may be on
|
|
|
|
* an inconsistent state and won't be able to do a clean cleanup
|
|
|
|
*/
|
|
|
|
static int reboot_emergency;
|
|
|
|
|
2008-11-12 00:19:48 +00:00
|
|
|
/* This is set by the PCI code if either type 1 or type 2 PCI is detected */
|
|
|
|
bool port_cf9_safe = false;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
|
|
|
* Reboot options and system auto-detection code provided by
|
|
|
|
* Dell Inc. so their systems "just work". :-)
|
|
|
|
*/
|
|
|
|
|
2016-07-14 10:05:56 +00:00
|
|
|
/*
|
|
|
|
* Some machines require the "reboot=a" commandline options
|
|
|
|
*/
|
|
|
|
static int __init set_acpi_reboot(const struct dmi_system_id *d)
|
|
|
|
{
|
|
|
|
if (reboot_type != BOOT_ACPI) {
|
|
|
|
reboot_type = BOOT_ACPI;
|
|
|
|
pr_info("%s series board detected. Selecting %s-method for reboots.\n",
|
|
|
|
d->ident, "ACPI");
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/*
|
2011-12-05 13:53:53 +00:00
|
|
|
* Some machines require the "reboot=b" or "reboot=k" commandline options,
|
2008-01-30 12:32:51 +00:00
|
|
|
* this quirk makes that automatic.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2007-10-03 19:15:40 +00:00
|
|
|
static int __init set_bios_reboot(const struct dmi_system_id *d)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-01-30 12:32:51 +00:00
|
|
|
if (reboot_type != BOOT_BIOS) {
|
|
|
|
reboot_type = BOOT_BIOS;
|
2012-05-22 02:50:07 +00:00
|
|
|
pr_info("%s series board detected. Selecting %s-method for reboots.\n",
|
2013-10-24 07:11:33 +00:00
|
|
|
d->ident, "BIOS");
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-04-12 08:01:53 +00:00
|
|
|
/*
|
|
|
|
* Some machines don't handle the default ACPI reboot method and
|
|
|
|
* require the EFI reboot method:
|
|
|
|
*/
|
|
|
|
static int __init set_efi_reboot(const struct dmi_system_id *d)
|
|
|
|
{
|
|
|
|
if (reboot_type != BOOT_EFI && !efi_runtime_disabled()) {
|
|
|
|
reboot_type = BOOT_EFI;
|
|
|
|
pr_info("%s series board detected. Selecting EFI-method for reboot.\n", d->ident);
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-06-17 04:47:37 +00:00
|
|
|
void __noreturn machine_real_restart(unsigned int type)
|
2012-02-01 15:05:00 +00:00
|
|
|
{
|
|
|
|
local_irq_disable();
|
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/*
|
|
|
|
* Write zero to CMOS register number 0x0f, which the BIOS POST
|
|
|
|
* routine will recognize as telling it to do a proper reboot. (Well
|
|
|
|
* that's what this book in front of me says -- it may only apply to
|
|
|
|
* the Phoenix BIOS though, it's not clear). At the same time,
|
|
|
|
* disable NMIs by setting the top bit in the CMOS address register,
|
|
|
|
* as we're about to do peculiar things to the CPU. I'm not sure if
|
|
|
|
* `outb_p' is needed instead of just `outb'. Use it to be on the
|
|
|
|
* safe side. (Yes, CMOS_WRITE does outb_p's. - Paul G.)
|
2012-02-01 15:05:00 +00:00
|
|
|
*/
|
|
|
|
spin_lock(&rtc_lock);
|
|
|
|
CMOS_WRITE(0x00, 0x8f);
|
|
|
|
spin_unlock(&rtc_lock);
|
|
|
|
|
|
|
|
/*
|
2021-12-02 15:32:25 +00:00
|
|
|
* Switch to the trampoline page table.
|
2012-02-01 15:05:00 +00:00
|
|
|
*/
|
2021-12-02 15:32:25 +00:00
|
|
|
load_trampoline_pgtable();
|
2012-02-01 15:05:00 +00:00
|
|
|
|
|
|
|
/* Jump to the identity-mapped low memory code */
|
2012-06-17 04:47:37 +00:00
|
|
|
#ifdef CONFIG_X86_32
|
|
|
|
asm volatile("jmpl *%0" : :
|
|
|
|
"rm" (real_mode_header->machine_real_restart_asm),
|
|
|
|
"a" (type));
|
|
|
|
#else
|
|
|
|
asm volatile("ljmpl *%0" : :
|
|
|
|
"m" (real_mode_header->machine_real_restart_asm),
|
|
|
|
"D" (type));
|
|
|
|
#endif
|
|
|
|
unreachable();
|
2012-02-01 15:05:00 +00:00
|
|
|
}
|
|
|
|
#ifdef CONFIG_APM_MODULE
|
|
|
|
EXPORT_SYMBOL(machine_real_restart);
|
|
|
|
#endif
|
2017-06-28 15:11:06 +00:00
|
|
|
STACK_FRAME_NON_STANDARD(machine_real_restart);
|
2012-02-01 15:05:00 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Some Apple MacBook and MacBookPro's needs reboot=p to be able to reboot
|
|
|
|
*/
|
|
|
|
static int __init set_pci_reboot(const struct dmi_system_id *d)
|
|
|
|
{
|
2014-04-04 06:41:26 +00:00
|
|
|
if (reboot_type != BOOT_CF9_FORCE) {
|
|
|
|
reboot_type = BOOT_CF9_FORCE;
|
2012-05-22 02:50:07 +00:00
|
|
|
pr_info("%s series board detected. Selecting %s-method for reboots.\n",
|
2013-10-24 07:11:33 +00:00
|
|
|
d->ident, "PCI");
|
2012-02-01 15:05:00 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-12-05 13:53:53 +00:00
|
|
|
static int __init set_kbd_reboot(const struct dmi_system_id *d)
|
|
|
|
{
|
|
|
|
if (reboot_type != BOOT_KBD) {
|
|
|
|
reboot_type = BOOT_KBD;
|
2012-05-22 02:50:07 +00:00
|
|
|
pr_info("%s series board detected. Selecting %s-method for reboot.\n",
|
2013-10-24 07:11:33 +00:00
|
|
|
d->ident, "KBD");
|
2011-12-05 13:53:53 +00:00
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/*
|
2012-06-17 04:47:37 +00:00
|
|
|
* This is a single dmi_table handling all reboot quirks.
|
2012-02-01 15:05:00 +00:00
|
|
|
*/
|
2017-09-14 09:59:30 +00:00
|
|
|
static const struct dmi_system_id reboot_dmi_table[] __initconst = {
|
2013-10-01 20:36:55 +00:00
|
|
|
|
|
|
|
/* Acer */
|
|
|
|
{ /* Handle reboot issue on Acer Aspire one */
|
|
|
|
.callback = set_kbd_reboot,
|
|
|
|
.ident = "Acer Aspire One A110",
|
2007-06-01 07:46:40 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "AOA110"),
|
2007-06-01 07:46:40 +00:00
|
|
|
},
|
|
|
|
},
|
2019-04-12 08:01:53 +00:00
|
|
|
{ /* Handle reboot issue on Acer TravelMate X514-51T */
|
|
|
|
.callback = set_efi_reboot,
|
|
|
|
.ident = "Acer TravelMate X514-51T",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate X514-51T"),
|
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
|
|
|
|
/* Apple */
|
|
|
|
{ /* Handle problems with rebooting on Apple MacBook5 */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Apple MacBook5",
|
2005-04-16 22:20:36 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "MacBook5"),
|
2005-04-16 22:20:36 +00:00
|
|
|
},
|
|
|
|
},
|
2020-04-25 20:06:41 +00:00
|
|
|
{ /* Handle problems with rebooting on Apple MacBook6,1 */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Apple MacBook6,1",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "MacBook6,1"),
|
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Apple MacBookPro5 */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Apple MacBookPro5",
|
2005-04-16 22:20:36 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro5"),
|
2005-04-16 22:20:36 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Apple Macmini3,1 */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Apple Macmini3,1",
|
2007-07-21 15:11:11 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Macmini3,1"),
|
2007-07-21 15:11:11 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on the iMac9,1. */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Apple iMac9,1",
|
2008-03-04 23:05:41 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "iMac9,1"),
|
2008-03-04 23:05:41 +00:00
|
|
|
},
|
|
|
|
},
|
2015-12-18 19:24:06 +00:00
|
|
|
{ /* Handle problems with rebooting on the iMac10,1. */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Apple iMac10,1",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "iMac10,1"),
|
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
|
2015-03-30 20:44:27 +00:00
|
|
|
/* ASRock */
|
|
|
|
{ /* Handle problems with rebooting on ASRock Q1900DC-ITX */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "ASRock Q1900DC-ITX",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR, "ASRock"),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "Q1900DC-ITX"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
|
2013-10-01 20:36:55 +00:00
|
|
|
/* ASUS */
|
|
|
|
{ /* Handle problems with rebooting on ASUS P4S800 */
|
2008-03-12 15:27:56 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "ASUS P4S800",
|
2008-03-12 15:27:56 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_BOARD_VENDOR, "ASUSTeK Computer INC."),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "P4S800"),
|
2008-03-12 15:27:56 +00:00
|
|
|
},
|
|
|
|
},
|
2017-02-19 18:32:48 +00:00
|
|
|
{ /* Handle problems with rebooting on ASUS EeeBook X205TA */
|
|
|
|
.callback = set_acpi_reboot,
|
|
|
|
.ident = "ASUS EeeBook X205TA",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
2017-03-09 13:00:17 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X205TA"),
|
2017-02-19 18:32:48 +00:00
|
|
|
},
|
|
|
|
},
|
2017-03-05 18:16:44 +00:00
|
|
|
{ /* Handle problems with rebooting on ASUS EeeBook X205TAW */
|
|
|
|
.callback = set_acpi_reboot,
|
|
|
|
.ident = "ASUS EeeBook X205TAW",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "X205TAW"),
|
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
|
2014-05-07 07:01:54 +00:00
|
|
|
/* Certec */
|
|
|
|
{ /* Handle problems with rebooting on Certec BPC600 */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Certec BPC600",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Certec"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "BPC600"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
|
2013-10-01 20:36:55 +00:00
|
|
|
/* Dell */
|
|
|
|
{ /* Handle problems with rebooting on Dell DXP061 */
|
2008-11-14 06:55:51 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell DXP061",
|
2008-11-14 06:55:51 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Dell DXP061"),
|
2008-11-14 06:55:51 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell E520's */
|
2009-06-05 10:02:38 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell E520",
|
2009-06-05 10:02:38 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Dell DM061"),
|
2009-06-05 10:02:38 +00:00
|
|
|
},
|
|
|
|
},
|
2013-11-12 02:33:38 +00:00
|
|
|
{ /* Handle problems with rebooting on the Latitude E5410. */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Dell Latitude E5410",
|
2010-01-27 23:29:18 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-11-12 02:33:38 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E5410"),
|
2010-01-27 23:29:18 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on the Latitude E5420. */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Dell Latitude E5420",
|
2005-04-16 22:20:36 +00:00
|
|
|
.matches = {
|
2010-01-27 23:29:18 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E5420"),
|
2005-04-16 22:20:36 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on the Latitude E6320. */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Dell Latitude E6320",
|
2008-07-17 11:50:15 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6320"),
|
2008-07-17 11:50:15 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on the Latitude E6420. */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Dell Latitude E6420",
|
2010-06-19 13:32:25 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Latitude E6420"),
|
2010-06-19 13:32:25 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell Optiplex 330 with 0KP561 */
|
2005-11-30 03:34:35 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell OptiPlex 330",
|
2005-11-30 03:34:35 +00:00
|
|
|
.matches = {
|
2010-06-19 13:32:25 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 330"),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "0KP561"),
|
2005-11-30 03:34:35 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell Optiplex 360 with 0T656F */
|
2009-03-04 19:53:00 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell OptiPlex 360",
|
2009-03-04 19:53:00 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 360"),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "0T656F"),
|
2009-03-04 19:53:00 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell Optiplex 745's SFF */
|
2009-03-26 20:45:28 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell OptiPlex 745",
|
2009-03-26 20:45:28 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
|
2009-03-26 20:45:28 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell Optiplex 745's DFF */
|
2009-05-22 03:35:50 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell OptiPlex 745",
|
2009-05-22 03:35:50 +00:00
|
|
|
.matches = {
|
2009-03-26 20:45:28 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "0MM599"),
|
2009-05-22 03:35:50 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell Optiplex 745 with 0KW626 */
|
2009-12-04 23:42:22 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell OptiPlex 745",
|
2011-07-06 00:56:30 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 745"),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "0KW626"),
|
2011-07-06 00:56:30 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell OptiPlex 760 with 0G919G */
|
2009-12-04 23:42:22 +00:00
|
|
|
.callback = set_bios_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell OptiPlex 760",
|
2009-08-03 12:47:32 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 760"),
|
|
|
|
DMI_MATCH(DMI_BOARD_NAME, "0G919G"),
|
2009-08-03 12:47:32 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on the OptiPlex 990. */
|
2009-08-04 16:39:31 +00:00
|
|
|
.callback = set_pci_reboot,
|
x86/reboot: Limit Dell Optiplex 990 quirk to early BIOS versions
When this platform was relatively new in November 2011, with early BIOS
revisions, a reboot quirk was added in commit 6be30bb7d750 ("x86/reboot:
Blacklist Dell OptiPlex 990 known to require PCI reboot")
However, this quirk (and several others) are open-ended to all BIOS
versions and left no automatic expiry if/when the system BIOS fixed the
issue, meaning that nobody is likely to come along and re-test.
What is really problematic with using PCI reboot as this quirk does, is
that it causes this platform to do a full power down, wait one second,
and then power back on. This is less than ideal if one is using it for
boot testing and/or bisecting kernels when legacy rotating hard disks
are installed.
It was only by chance that the quirk was noticed in dmesg - and when
disabled it turned out that it wasn't required anymore (BIOS A24), and a
default reboot would work fine without the "harshness" of power cycling the
machine (and disks) down and up like the PCI reboot does.
Doing a bit more research, it seems that the "newest" BIOS for which the
issue was reported[1] was version A06, however Dell[2] seemed to suggest
only up to and including version A05, with the A06 having a large number of
fixes[3] listed.
As is typical with a new platform, the initial BIOS updates come frequently
and then taper off (and in this case, with a revival for CPU CVEs); a
search for O990-A<ver>.exe reveals the following dates:
A02 16 Mar 2011
A03 11 May 2011
A06 14 Sep 2011
A07 24 Oct 2011
A10 08 Dec 2011
A14 06 Sep 2012
A16 15 Oct 2012
A18 30 Sep 2013
A19 23 Sep 2015
A20 02 Jun 2017
A23 07 Mar 2018
A24 21 Aug 2018
While it's overkill to flash and test each of the above, it would seem
likely that the issue was contained within A0x BIOS versions, given the
dates above and the dates of issue reports[4] from distros. So rather than
just throw out the quirk entirely, limit the scope to just those early BIOS
versions, in case people are still running systems from 2011 with the
original as-shipped early A0x BIOS versions.
[1] https://lore.kernel.org/lkml/1320373471-3942-1-git-send-email-trenn@suse.de/
[2] https://www.dell.com/support/kbdoc/en-ca/000131908/linux-based-operating-systems-stall-upon-reboot-on-optiplex-390-790-990-systems
[3] https://www.dell.com/support/home/en-ca/drivers/driversdetails?driverid=85j10
[4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/768039
Fixes: 6be30bb7d750 ("x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot")
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210530162447.996461-4-paul.gortmaker@windriver.com
2021-05-30 16:24:47 +00:00
|
|
|
.ident = "Dell OptiPlex 990 BIOS A0x",
|
2009-08-04 16:39:31 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 990"),
|
x86/reboot: Limit Dell Optiplex 990 quirk to early BIOS versions
When this platform was relatively new in November 2011, with early BIOS
revisions, a reboot quirk was added in commit 6be30bb7d750 ("x86/reboot:
Blacklist Dell OptiPlex 990 known to require PCI reboot")
However, this quirk (and several others) are open-ended to all BIOS
versions and left no automatic expiry if/when the system BIOS fixed the
issue, meaning that nobody is likely to come along and re-test.
What is really problematic with using PCI reboot as this quirk does, is
that it causes this platform to do a full power down, wait one second,
and then power back on. This is less than ideal if one is using it for
boot testing and/or bisecting kernels when legacy rotating hard disks
are installed.
It was only by chance that the quirk was noticed in dmesg - and when
disabled it turned out that it wasn't required anymore (BIOS A24), and a
default reboot would work fine without the "harshness" of power cycling the
machine (and disks) down and up like the PCI reboot does.
Doing a bit more research, it seems that the "newest" BIOS for which the
issue was reported[1] was version A06, however Dell[2] seemed to suggest
only up to and including version A05, with the A06 having a large number of
fixes[3] listed.
As is typical with a new platform, the initial BIOS updates come frequently
and then taper off (and in this case, with a revival for CPU CVEs); a
search for O990-A<ver>.exe reveals the following dates:
A02 16 Mar 2011
A03 11 May 2011
A06 14 Sep 2011
A07 24 Oct 2011
A10 08 Dec 2011
A14 06 Sep 2012
A16 15 Oct 2012
A18 30 Sep 2013
A19 23 Sep 2015
A20 02 Jun 2017
A23 07 Mar 2018
A24 21 Aug 2018
While it's overkill to flash and test each of the above, it would seem
likely that the issue was contained within A0x BIOS versions, given the
dates above and the dates of issue reports[4] from distros. So rather than
just throw out the quirk entirely, limit the scope to just those early BIOS
versions, in case people are still running systems from 2011 with the
original as-shipped early A0x BIOS versions.
[1] https://lore.kernel.org/lkml/1320373471-3942-1-git-send-email-trenn@suse.de/
[2] https://www.dell.com/support/kbdoc/en-ca/000131908/linux-based-operating-systems-stall-upon-reboot-on-optiplex-390-790-990-systems
[3] https://www.dell.com/support/home/en-ca/drivers/driversdetails?driverid=85j10
[4] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/768039
Fixes: 6be30bb7d750 ("x86/reboot: Blacklist Dell OptiPlex 990 known to require PCI reboot")
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210530162447.996461-4-paul.gortmaker@windriver.com
2021-05-30 16:24:47 +00:00
|
|
|
DMI_MATCH(DMI_BIOS_VERSION, "A0"),
|
2009-08-04 16:39:31 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell 300's */
|
|
|
|
.callback = set_bios_reboot,
|
|
|
|
.ident = "Dell PowerEdge 300",
|
2009-11-02 10:51:11 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 300/"),
|
2009-11-02 10:51:11 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell 1300's */
|
|
|
|
.callback = set_bios_reboot,
|
|
|
|
.ident = "Dell PowerEdge 1300",
|
2010-02-16 23:17:29 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 1300/"),
|
2010-02-16 23:17:29 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell 2400's */
|
|
|
|
.callback = set_bios_reboot,
|
|
|
|
.ident = "Dell PowerEdge 2400",
|
2011-06-28 13:57:31 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Computer Corporation"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "PowerEdge 2400"),
|
2011-06-28 13:57:31 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on the Dell PowerEdge C6100. */
|
2013-10-04 12:16:04 +00:00
|
|
|
.callback = set_pci_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell PowerEdge C6100",
|
2013-10-04 12:16:04 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "C6100"),
|
2013-10-04 12:16:04 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on the Precision M6600. */
|
2011-05-13 01:04:59 +00:00
|
|
|
.callback = set_pci_reboot,
|
2013-10-01 20:36:55 +00:00
|
|
|
.ident = "Dell Precision M6600",
|
2011-05-13 01:04:59 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Precision M6600"),
|
2011-05-13 01:04:59 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell T5400's */
|
|
|
|
.callback = set_bios_reboot,
|
|
|
|
.ident = "Dell Precision T5400",
|
2011-07-21 18:22:21 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation T5400"),
|
2011-07-21 18:22:21 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell T7400's */
|
|
|
|
.callback = set_bios_reboot,
|
|
|
|
.ident = "Dell Precision T7400",
|
2011-11-15 23:19:51 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Precision WorkStation T7400"),
|
2011-11-15 23:19:51 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell XPS710 */
|
|
|
|
.callback = set_bios_reboot,
|
|
|
|
.ident = "Dell XPS710",
|
2012-02-20 06:20:06 +00:00
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "Dell XPS710"),
|
2012-02-20 06:20:06 +00:00
|
|
|
},
|
|
|
|
},
|
2016-07-14 10:05:56 +00:00
|
|
|
{ /* Handle problems with rebooting on Dell Optiplex 7450 AIO */
|
|
|
|
.callback = set_acpi_reboot,
|
|
|
|
.ident = "Dell OptiPlex 7450 AIO",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "OptiPlex 7450 AIO"),
|
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
|
|
|
|
/* Hewlett-Packard */
|
|
|
|
{ /* Handle problems with rebooting on HP laptops */
|
|
|
|
.callback = set_bios_reboot,
|
|
|
|
.ident = "HP Compaq Laptop",
|
2013-09-20 22:59:07 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "HP Compaq"),
|
2013-09-20 22:59:07 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
|
2020-12-01 11:39:57 +00:00
|
|
|
{ /* PCIe Wifi card isn't detected after reboot otherwise */
|
|
|
|
.callback = set_pci_reboot,
|
|
|
|
.ident = "Zotac ZBOX CI327 nano",
|
|
|
|
.matches = {
|
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "NA"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "ZBOX-CI327NANO-GS-01"),
|
|
|
|
},
|
|
|
|
},
|
|
|
|
|
2013-10-01 20:36:55 +00:00
|
|
|
/* Sony */
|
|
|
|
{ /* Handle problems with rebooting on Sony VGN-Z540N */
|
|
|
|
.callback = set_bios_reboot,
|
|
|
|
.ident = "Sony VGN-Z540N",
|
2013-09-20 22:59:07 +00:00
|
|
|
.matches = {
|
2013-10-01 20:36:55 +00:00
|
|
|
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
|
|
|
|
DMI_MATCH(DMI_PRODUCT_NAME, "VGN-Z540N"),
|
2013-09-20 22:59:07 +00:00
|
|
|
},
|
|
|
|
},
|
2013-10-01 20:36:55 +00:00
|
|
|
|
2009-08-03 12:47:32 +00:00
|
|
|
{ }
|
|
|
|
};
|
|
|
|
|
2012-02-01 15:05:00 +00:00
|
|
|
static int __init reboot_init(void)
|
2009-08-03 12:47:32 +00:00
|
|
|
{
|
2014-06-13 11:39:55 +00:00
|
|
|
int rv;
|
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/*
|
|
|
|
* Only do the DMI check if reboot_type hasn't been overridden
|
2012-01-29 19:17:22 +00:00
|
|
|
* on the command line
|
|
|
|
*/
|
2014-06-13 11:39:55 +00:00
|
|
|
if (!reboot_default)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The DMI quirks table takes precedence. If no quirks entry
|
2017-07-24 12:22:48 +00:00
|
|
|
* matches and the ACPI Hardware Reduced bit is set and EFI
|
|
|
|
* runtime services are enabled, force EFI reboot.
|
2014-06-13 11:39:55 +00:00
|
|
|
*/
|
|
|
|
rv = dmi_check_system(reboot_dmi_table);
|
|
|
|
|
2017-07-24 12:22:48 +00:00
|
|
|
if (!rv && efi_reboot_required() && !efi_runtime_disabled())
|
2014-06-13 11:39:55 +00:00
|
|
|
reboot_type = BOOT_EFI;
|
|
|
|
|
2009-08-03 12:47:32 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2012-02-01 15:05:00 +00:00
|
|
|
core_initcall(reboot_init);
|
2009-08-03 12:47:32 +00:00
|
|
|
|
2008-01-30 12:32:51 +00:00
|
|
|
static inline void kb_wait(void)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
2008-01-30 12:33:25 +00:00
|
|
|
for (i = 0; i < 0x10000; i++) {
|
|
|
|
if ((inb(0x64) & 0x02) == 0)
|
2008-01-30 12:32:51 +00:00
|
|
|
break;
|
2008-01-30 12:33:25 +00:00
|
|
|
udelay(2);
|
|
|
|
}
|
2008-01-30 12:32:51 +00:00
|
|
|
}
|
|
|
|
|
2011-09-30 19:06:21 +00:00
|
|
|
static void vmxoff_nmi(int cpu, struct pt_regs *regs)
|
2008-11-17 21:03:24 +00:00
|
|
|
{
|
|
|
|
cpu_emergency_vmxoff();
|
|
|
|
}
|
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/* Use NMIs as IPIs to tell all CPUs to disable virtualization */
|
2008-11-17 21:03:24 +00:00
|
|
|
static void emergency_vmx_disable_all(void)
|
|
|
|
{
|
|
|
|
/* Just make sure we won't change CPUs while doing this */
|
|
|
|
local_irq_disable();
|
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/*
|
2020-12-31 00:26:55 +00:00
|
|
|
* Disable VMX on all CPUs before rebooting, otherwise we risk hanging
|
|
|
|
* the machine, because the CPU blocks INIT when it's in VMX root.
|
2008-11-17 21:03:24 +00:00
|
|
|
*
|
2020-12-31 00:26:55 +00:00
|
|
|
* We can't take any locks and we may be on an inconsistent state, so
|
|
|
|
* use NMIs as IPIs to tell the other CPUs to exit VMX root and halt.
|
2008-11-17 21:03:24 +00:00
|
|
|
*
|
2020-12-31 00:26:55 +00:00
|
|
|
* Do the NMI shootdown even if VMX if off on _this_ CPU, as that
|
|
|
|
* doesn't prevent a different CPU from being in VMX root operation.
|
2008-11-17 21:03:24 +00:00
|
|
|
*/
|
2020-12-31 00:26:55 +00:00
|
|
|
if (cpu_has_vmx()) {
|
|
|
|
/* Safely force _this_ CPU out of VMX root operation. */
|
|
|
|
__cpu_emergency_vmxoff();
|
2008-11-17 21:03:24 +00:00
|
|
|
|
2020-12-31 00:26:55 +00:00
|
|
|
/* Halt and exit VMX root operation on the other CPUs. */
|
2008-11-17 21:03:24 +00:00
|
|
|
nmi_shootdown_cpus(vmxoff_nmi);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2008-03-06 17:29:43 +00:00
|
|
|
void __attribute__((weak)) mach_reboot_fixups(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2011-04-04 17:55:05 +00:00
|
|
|
/*
|
2014-04-04 06:41:26 +00:00
|
|
|
* To the best of our knowledge Windows compatible x86 hardware expects
|
|
|
|
* the following on reboot:
|
2011-04-04 17:55:05 +00:00
|
|
|
*
|
|
|
|
* 1) If the FADT has the ACPI reboot register flag set, try it
|
|
|
|
* 2) If still alive, write to the keyboard controller
|
|
|
|
* 3) If still alive, write to the ACPI reboot register again
|
|
|
|
* 4) If still alive, write to the keyboard controller again
|
2014-03-02 10:39:02 +00:00
|
|
|
* 5) If still alive, call the EFI runtime service to reboot
|
2014-04-04 06:41:26 +00:00
|
|
|
* 6) If no EFI runtime service, call the BIOS to do a reboot
|
2011-04-04 17:55:05 +00:00
|
|
|
*
|
2014-04-04 06:41:26 +00:00
|
|
|
* We default to following the same pattern. We also have
|
|
|
|
* two other reboot methods: 'triple fault' and 'PCI', which
|
|
|
|
* can be triggered via the reboot= kernel boot option or
|
|
|
|
* via quirks.
|
|
|
|
*
|
|
|
|
* This means that this function can never return, it can misbehave
|
|
|
|
* by not rebooting properly and hanging.
|
2011-04-04 17:55:05 +00:00
|
|
|
*/
|
2008-02-12 23:37:48 +00:00
|
|
|
static void native_machine_emergency_restart(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2008-01-30 12:32:51 +00:00
|
|
|
int i;
|
2011-04-04 17:55:05 +00:00
|
|
|
int attempt = 0;
|
|
|
|
int orig_reboot_type = reboot_type;
|
2013-07-08 23:01:35 +00:00
|
|
|
unsigned short mode;
|
2008-01-30 12:32:51 +00:00
|
|
|
|
2008-11-17 21:03:24 +00:00
|
|
|
if (reboot_emergency)
|
|
|
|
emergency_vmx_disable_all();
|
|
|
|
|
2009-07-01 02:31:02 +00:00
|
|
|
tboot_shutdown(TB_SHUTDOWN_REBOOT);
|
|
|
|
|
2008-01-30 12:32:51 +00:00
|
|
|
/* Tell the BIOS if we want cold or warm reboot */
|
2013-07-08 23:01:35 +00:00
|
|
|
mode = reboot_mode == REBOOT_WARM ? 0x1234 : 0;
|
|
|
|
*((unsigned short *)__va(0x472)) = mode;
|
2008-01-30 12:32:51 +00:00
|
|
|
|
2016-04-25 20:07:00 +00:00
|
|
|
/*
|
|
|
|
* If an EFI capsule has been registered with the firmware then
|
|
|
|
* override the reboot= parameter.
|
|
|
|
*/
|
|
|
|
if (efi_capsule_pending(NULL)) {
|
|
|
|
pr_info("EFI capsule is pending, forcing EFI reboot.\n");
|
|
|
|
reboot_type = BOOT_EFI;
|
|
|
|
}
|
|
|
|
|
2008-01-30 12:32:51 +00:00
|
|
|
for (;;) {
|
|
|
|
/* Could also try the reset bit in the Hammer NB */
|
|
|
|
switch (reboot_type) {
|
2014-04-04 06:41:26 +00:00
|
|
|
case BOOT_ACPI:
|
|
|
|
acpi_reboot();
|
|
|
|
reboot_type = BOOT_KBD;
|
|
|
|
break;
|
|
|
|
|
2008-01-30 12:32:51 +00:00
|
|
|
case BOOT_KBD:
|
2012-02-01 15:06:34 +00:00
|
|
|
mach_reboot_fixups(); /* For board specific fixups */
|
2008-03-06 17:29:43 +00:00
|
|
|
|
2008-01-30 12:32:51 +00:00
|
|
|
for (i = 0; i < 10; i++) {
|
|
|
|
kb_wait();
|
|
|
|
udelay(50);
|
2012-02-01 15:06:34 +00:00
|
|
|
outb(0xfe, 0x64); /* Pulse reset low */
|
2008-01-30 12:32:51 +00:00
|
|
|
udelay(50);
|
|
|
|
}
|
2011-04-04 17:55:05 +00:00
|
|
|
if (attempt == 0 && orig_reboot_type == BOOT_ACPI) {
|
|
|
|
attempt = 1;
|
|
|
|
reboot_type = BOOT_ACPI;
|
|
|
|
} else {
|
2014-03-02 10:39:02 +00:00
|
|
|
reboot_type = BOOT_EFI;
|
2011-04-04 17:55:05 +00:00
|
|
|
}
|
|
|
|
break;
|
2008-01-30 12:32:51 +00:00
|
|
|
|
|
|
|
case BOOT_EFI:
|
2014-06-13 11:22:22 +00:00
|
|
|
efi_reboot(reboot_mode, NULL);
|
2014-04-04 06:41:26 +00:00
|
|
|
reboot_type = BOOT_BIOS;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case BOOT_BIOS:
|
|
|
|
machine_real_restart(MRR_BIOS);
|
|
|
|
|
|
|
|
/* We're probably dead after this, but... */
|
|
|
|
reboot_type = BOOT_CF9_SAFE;
|
2008-11-12 00:19:48 +00:00
|
|
|
break;
|
2008-01-30 12:32:51 +00:00
|
|
|
|
2014-04-04 06:41:26 +00:00
|
|
|
case BOOT_CF9_FORCE:
|
2008-11-12 00:19:48 +00:00
|
|
|
port_cf9_safe = true;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2008-01-30 12:32:51 +00:00
|
|
|
|
2014-04-04 06:41:26 +00:00
|
|
|
case BOOT_CF9_SAFE:
|
2008-11-12 00:19:48 +00:00
|
|
|
if (port_cf9_safe) {
|
2014-04-04 06:41:26 +00:00
|
|
|
u8 reboot_code = reboot_mode == REBOOT_WARM ? 0x06 : 0x0E;
|
2013-08-21 08:13:57 +00:00
|
|
|
u8 cf9 = inb(0xcf9) & ~reboot_code;
|
2008-11-12 00:19:48 +00:00
|
|
|
outb(cf9|2, 0xcf9); /* Request hard reset */
|
|
|
|
udelay(50);
|
2013-08-21 08:13:57 +00:00
|
|
|
/* Actually do the reset */
|
|
|
|
outb(cf9|reboot_code, 0xcf9);
|
2008-11-12 00:19:48 +00:00
|
|
|
udelay(50);
|
|
|
|
}
|
2014-04-04 06:41:26 +00:00
|
|
|
reboot_type = BOOT_TRIPLE;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case BOOT_TRIPLE:
|
2021-05-19 21:21:50 +00:00
|
|
|
idt_invalidate();
|
2014-04-04 06:41:26 +00:00
|
|
|
__asm__ __volatile__("int3");
|
|
|
|
|
|
|
|
/* We're probably dead after this, but... */
|
|
|
|
reboot_type = BOOT_KBD;
|
2008-01-30 12:32:51 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-17 19:08:39 +00:00
|
|
|
void native_machine_shutdown(void)
|
2008-01-30 12:32:51 +00:00
|
|
|
{
|
|
|
|
/* Stop the cpus and apics */
|
2013-10-24 01:30:12 +00:00
|
|
|
#ifdef CONFIG_X86_IO_APIC
|
2013-12-05 00:07:49 +00:00
|
|
|
/*
|
|
|
|
* Disabling IO APIC before local APIC is a workaround for
|
|
|
|
* erratum AVR31 in "Intel Atom Processor C2000 Product Family
|
|
|
|
* Specification Update". In this situation, interrupts that target
|
|
|
|
* a Logical Processor whose Local APIC is either in the process of
|
|
|
|
* being hardware disabled or software disabled are neither delivered
|
|
|
|
* nor discarded. When this erratum occurs, the processor may hang.
|
|
|
|
*
|
|
|
|
* Even without the erratum, it still makes sense to quiet IO APIC
|
|
|
|
* before disabling Local APIC.
|
|
|
|
*/
|
2018-02-14 05:46:53 +00:00
|
|
|
clear_IO_APIC();
|
2013-10-24 01:30:12 +00:00
|
|
|
#endif
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#ifdef CONFIG_SMP
|
2012-02-01 15:06:34 +00:00
|
|
|
/*
|
2013-07-08 23:01:42 +00:00
|
|
|
* Stop all of the others. Also disable the local irq to
|
|
|
|
* not receive the per-cpu timer interrupt which may trigger
|
|
|
|
* scheduler's load balance.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2012-05-30 15:15:41 +00:00
|
|
|
local_irq_disable();
|
2010-10-11 21:37:08 +00:00
|
|
|
stop_other_cpus();
|
2008-01-30 12:32:51 +00:00
|
|
|
#endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
lapic_shutdown();
|
2018-02-14 05:46:53 +00:00
|
|
|
restore_boot_irq_mode();
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-12-03 16:17:10 +00:00
|
|
|
#ifdef CONFIG_HPET_TIMER
|
|
|
|
hpet_disable();
|
|
|
|
#endif
|
2005-06-25 21:57:55 +00:00
|
|
|
|
2008-01-30 12:32:51 +00:00
|
|
|
#ifdef CONFIG_X86_64
|
2009-10-27 07:34:44 +00:00
|
|
|
x86_platform.iommu_shutdown();
|
2008-01-30 12:32:51 +00:00
|
|
|
#endif
|
2007-05-02 17:27:06 +00:00
|
|
|
}
|
|
|
|
|
2008-11-17 21:03:24 +00:00
|
|
|
static void __machine_emergency_restart(int emergency)
|
|
|
|
{
|
|
|
|
reboot_emergency = emergency;
|
|
|
|
machine_ops.emergency_restart();
|
|
|
|
}
|
|
|
|
|
2008-02-12 23:37:48 +00:00
|
|
|
static void native_machine_restart(char *__unused)
|
2005-06-25 21:57:55 +00:00
|
|
|
{
|
2012-05-22 02:50:07 +00:00
|
|
|
pr_notice("machine restart\n");
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2008-01-30 12:32:51 +00:00
|
|
|
if (!reboot_force)
|
|
|
|
machine_shutdown();
|
2008-11-17 21:03:24 +00:00
|
|
|
__machine_emergency_restart(0);
|
2005-07-26 17:41:26 +00:00
|
|
|
}
|
|
|
|
|
2008-02-12 23:37:48 +00:00
|
|
|
static void native_machine_halt(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2012-02-01 15:06:34 +00:00
|
|
|
/* Stop other cpus and apics */
|
2008-11-11 13:33:44 +00:00
|
|
|
machine_shutdown();
|
|
|
|
|
2009-07-01 02:31:02 +00:00
|
|
|
tboot_shutdown(TB_SHUTDOWN_HALT);
|
|
|
|
|
2008-11-11 13:33:44 +00:00
|
|
|
stop_this_cpu(NULL);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2008-02-12 23:37:48 +00:00
|
|
|
static void native_machine_power_off(void)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-01-11 21:43:12 +00:00
|
|
|
if (pm_power_off) {
|
2008-01-30 12:32:51 +00:00
|
|
|
if (!reboot_force)
|
|
|
|
machine_shutdown();
|
2005-04-16 22:20:36 +00:00
|
|
|
pm_power_off();
|
2006-01-11 21:43:12 +00:00
|
|
|
}
|
2012-02-01 15:06:34 +00:00
|
|
|
/* A fallback in case there is no PM info available */
|
2009-07-01 02:31:02 +00:00
|
|
|
tboot_shutdown(TB_SHUTDOWN_HALT);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
2016-08-08 23:29:06 +00:00
|
|
|
struct machine_ops machine_ops __ro_after_init = {
|
2008-02-12 23:37:48 +00:00
|
|
|
.power_off = native_machine_power_off,
|
|
|
|
.shutdown = native_machine_shutdown,
|
|
|
|
.emergency_restart = native_machine_emergency_restart,
|
|
|
|
.restart = native_machine_restart,
|
2008-03-17 19:08:38 +00:00
|
|
|
.halt = native_machine_halt,
|
2015-09-09 22:38:55 +00:00
|
|
|
#ifdef CONFIG_KEXEC_CORE
|
2008-03-17 19:08:38 +00:00
|
|
|
.crash_shutdown = native_machine_crash_shutdown,
|
|
|
|
#endif
|
2007-05-02 17:27:11 +00:00
|
|
|
};
|
2008-02-12 23:37:48 +00:00
|
|
|
|
|
|
|
void machine_power_off(void)
|
|
|
|
{
|
|
|
|
machine_ops.power_off();
|
|
|
|
}
|
|
|
|
|
|
|
|
void machine_shutdown(void)
|
|
|
|
{
|
|
|
|
machine_ops.shutdown();
|
|
|
|
}
|
|
|
|
|
|
|
|
void machine_emergency_restart(void)
|
|
|
|
{
|
2008-11-17 21:03:24 +00:00
|
|
|
__machine_emergency_restart(1);
|
2008-02-12 23:37:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void machine_restart(char *cmd)
|
|
|
|
{
|
|
|
|
machine_ops.restart(cmd);
|
|
|
|
}
|
|
|
|
|
|
|
|
void machine_halt(void)
|
|
|
|
{
|
|
|
|
machine_ops.halt();
|
|
|
|
}
|
|
|
|
|
2015-09-09 22:38:55 +00:00
|
|
|
#ifdef CONFIG_KEXEC_CORE
|
2008-03-17 19:08:38 +00:00
|
|
|
void machine_crash_shutdown(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
machine_ops.crash_shutdown(regs);
|
|
|
|
}
|
|
|
|
#endif
|
2008-11-12 13:34:42 +00:00
|
|
|
|
|
|
|
|
2017-03-13 09:50:19 +00:00
|
|
|
/* This is the CPU performing the emergency shutdown work. */
|
|
|
|
int crashing_cpu = -1;
|
|
|
|
|
2008-11-12 13:34:43 +00:00
|
|
|
#if defined(CONFIG_SMP)
|
2008-11-12 13:34:42 +00:00
|
|
|
|
|
|
|
static nmi_shootdown_cb shootdown_callback;
|
|
|
|
|
|
|
|
static atomic_t waiting_for_crash_ipi;
|
panic, x86: Allow CPUs to save registers even if looping in NMI context
Currently, kdump_nmi_shootdown_cpus(), a subroutine of crash_kexec(),
sends an NMI IPI to CPUs which haven't called panic() to stop them,
save their register information and do some cleanups for crash dumping.
However, if such a CPU is infinitely looping in NMI context, we fail to
save its register information into the crash dump.
For example, this can happen when unknown NMIs are broadcast to all
CPUs as follows:
CPU 0 CPU 1
=========================== ==========================
receive an unknown NMI
unknown_nmi_error()
panic() receive an unknown NMI
spin_trylock(&panic_lock) unknown_nmi_error()
crash_kexec() panic()
spin_trylock(&panic_lock)
panic_smp_self_stop()
infinite loop
kdump_nmi_shootdown_cpus()
issue NMI IPI -----------> blocked until IRET
infinite loop...
Here, since CPU 1 is in NMI context, the second NMI from CPU 0 is
blocked until CPU 1 executes IRET. However, CPU 1 never executes IRET,
so the NMI is not handled and the callback function to save registers is
never called.
In practice, this can happen on some servers which broadcast NMIs to all
CPUs when the NMI button is pushed.
To save registers in this case, we need to:
a) Return from NMI handler instead of looping infinitely
or
b) Call the callback function directly from the infinite loop
Inherently, a) is risky because NMI is also used to prevent corrupted
data from being propagated to devices. So, we chose b).
This patch does the following:
1. Move the infinite looping of CPUs which haven't called panic() in NMI
context (actually done by panic_smp_self_stop()) outside of panic() to
enable us to refer pt_regs. Please note that panic_smp_self_stop() is
still used for normal context.
2. Call a callback of kdump_nmi_shootdown_cpus() directly to save
registers and do some cleanups after setting waiting_for_crash_ipi which
is used for counting down the number of CPUs which handled the callback
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Aaron Tomlin <atomlin@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Gobinda Charan Maji <gobinda.cemk07@gmail.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: kexec@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: lkml <linux-kernel@vger.kernel.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Link: http://lkml.kernel.org/r/20151210014628.25437.75256.stgit@softrs
[ Cleanup comments, fixup formatting. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-12-14 10:19:10 +00:00
|
|
|
static int crash_ipi_issued;
|
2008-11-12 13:34:42 +00:00
|
|
|
|
2011-09-30 19:06:21 +00:00
|
|
|
static int crash_nmi_callback(unsigned int val, struct pt_regs *regs)
|
2008-11-12 13:34:42 +00:00
|
|
|
{
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
cpu = raw_smp_processor_id();
|
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/*
|
|
|
|
* Don't do anything if this handler is invoked on crashing cpu.
|
2008-11-12 13:34:42 +00:00
|
|
|
* Otherwise, system will completely hang. Crashing cpu can get
|
|
|
|
* an NMI if system was initially booted with nmi_watchdog parameter.
|
|
|
|
*/
|
|
|
|
if (cpu == crashing_cpu)
|
2011-09-30 19:06:21 +00:00
|
|
|
return NMI_HANDLED;
|
2008-11-12 13:34:42 +00:00
|
|
|
local_irq_disable();
|
|
|
|
|
2011-09-30 19:06:21 +00:00
|
|
|
shootdown_callback(cpu, regs);
|
2008-11-12 13:34:42 +00:00
|
|
|
|
|
|
|
atomic_dec(&waiting_for_crash_ipi);
|
|
|
|
/* Assume hlt works */
|
|
|
|
halt();
|
|
|
|
for (;;)
|
|
|
|
cpu_relax();
|
|
|
|
|
2011-09-30 19:06:21 +00:00
|
|
|
return NMI_HANDLED;
|
2008-11-12 13:34:42 +00:00
|
|
|
}
|
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/*
|
|
|
|
* Halt all other CPUs, calling the specified function on each of them
|
2008-11-12 13:34:43 +00:00
|
|
|
*
|
|
|
|
* This function can be used to halt all other CPUs on crash
|
|
|
|
* or emergency reboot time. The function passed as parameter
|
|
|
|
* will be called inside a NMI handler on all CPUs.
|
|
|
|
*/
|
2008-11-12 13:34:42 +00:00
|
|
|
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
|
|
|
|
{
|
|
|
|
unsigned long msecs;
|
2008-11-12 13:34:44 +00:00
|
|
|
local_irq_disable();
|
2008-11-12 13:34:42 +00:00
|
|
|
|
2012-02-01 15:06:34 +00:00
|
|
|
/* Make a note of crashing cpu. Will be used in NMI callback. */
|
2008-11-12 13:34:42 +00:00
|
|
|
crashing_cpu = safe_smp_processor_id();
|
|
|
|
|
|
|
|
shootdown_callback = callback;
|
|
|
|
|
|
|
|
atomic_set(&waiting_for_crash_ipi, num_online_cpus() - 1);
|
|
|
|
/* Would it be better to replace the trap vector here? */
|
2011-09-30 19:06:21 +00:00
|
|
|
if (register_nmi_handler(NMI_LOCAL, crash_nmi_callback,
|
|
|
|
NMI_FLAG_FIRST, "crash"))
|
2012-02-01 15:06:34 +00:00
|
|
|
return; /* Return what? */
|
|
|
|
/*
|
|
|
|
* Ensure the new callback function is set before sending
|
2008-11-12 13:34:42 +00:00
|
|
|
* out the NMI
|
|
|
|
*/
|
|
|
|
wmb();
|
|
|
|
|
2019-07-22 18:47:23 +00:00
|
|
|
apic_send_IPI_allbutself(NMI_VECTOR);
|
2008-11-12 13:34:42 +00:00
|
|
|
|
panic, x86: Allow CPUs to save registers even if looping in NMI context
Currently, kdump_nmi_shootdown_cpus(), a subroutine of crash_kexec(),
sends an NMI IPI to CPUs which haven't called panic() to stop them,
save their register information and do some cleanups for crash dumping.
However, if such a CPU is infinitely looping in NMI context, we fail to
save its register information into the crash dump.
For example, this can happen when unknown NMIs are broadcast to all
CPUs as follows:
CPU 0 CPU 1
=========================== ==========================
receive an unknown NMI
unknown_nmi_error()
panic() receive an unknown NMI
spin_trylock(&panic_lock) unknown_nmi_error()
crash_kexec() panic()
spin_trylock(&panic_lock)
panic_smp_self_stop()
infinite loop
kdump_nmi_shootdown_cpus()
issue NMI IPI -----------> blocked until IRET
infinite loop...
Here, since CPU 1 is in NMI context, the second NMI from CPU 0 is
blocked until CPU 1 executes IRET. However, CPU 1 never executes IRET,
so the NMI is not handled and the callback function to save registers is
never called.
In practice, this can happen on some servers which broadcast NMIs to all
CPUs when the NMI button is pushed.
To save registers in this case, we need to:
a) Return from NMI handler instead of looping infinitely
or
b) Call the callback function directly from the infinite loop
Inherently, a) is risky because NMI is also used to prevent corrupted
data from being propagated to devices. So, we chose b).
This patch does the following:
1. Move the infinite looping of CPUs which haven't called panic() in NMI
context (actually done by panic_smp_self_stop()) outside of panic() to
enable us to refer pt_regs. Please note that panic_smp_self_stop() is
still used for normal context.
2. Call a callback of kdump_nmi_shootdown_cpus() directly to save
registers and do some cleanups after setting waiting_for_crash_ipi which
is used for counting down the number of CPUs which handled the callback
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Aaron Tomlin <atomlin@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Gobinda Charan Maji <gobinda.cemk07@gmail.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: kexec@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: lkml <linux-kernel@vger.kernel.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Link: http://lkml.kernel.org/r/20151210014628.25437.75256.stgit@softrs
[ Cleanup comments, fixup formatting. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-12-14 10:19:10 +00:00
|
|
|
/* Kick CPUs looping in NMI context. */
|
|
|
|
WRITE_ONCE(crash_ipi_issued, 1);
|
|
|
|
|
2008-11-12 13:34:42 +00:00
|
|
|
msecs = 1000; /* Wait at most a second for the other cpus to stop */
|
|
|
|
while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
|
|
|
|
mdelay(1);
|
|
|
|
msecs--;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Leave the nmi callback set */
|
|
|
|
}
|
panic, x86: Allow CPUs to save registers even if looping in NMI context
Currently, kdump_nmi_shootdown_cpus(), a subroutine of crash_kexec(),
sends an NMI IPI to CPUs which haven't called panic() to stop them,
save their register information and do some cleanups for crash dumping.
However, if such a CPU is infinitely looping in NMI context, we fail to
save its register information into the crash dump.
For example, this can happen when unknown NMIs are broadcast to all
CPUs as follows:
CPU 0 CPU 1
=========================== ==========================
receive an unknown NMI
unknown_nmi_error()
panic() receive an unknown NMI
spin_trylock(&panic_lock) unknown_nmi_error()
crash_kexec() panic()
spin_trylock(&panic_lock)
panic_smp_self_stop()
infinite loop
kdump_nmi_shootdown_cpus()
issue NMI IPI -----------> blocked until IRET
infinite loop...
Here, since CPU 1 is in NMI context, the second NMI from CPU 0 is
blocked until CPU 1 executes IRET. However, CPU 1 never executes IRET,
so the NMI is not handled and the callback function to save registers is
never called.
In practice, this can happen on some servers which broadcast NMIs to all
CPUs when the NMI button is pushed.
To save registers in this case, we need to:
a) Return from NMI handler instead of looping infinitely
or
b) Call the callback function directly from the infinite loop
Inherently, a) is risky because NMI is also used to prevent corrupted
data from being propagated to devices. So, we chose b).
This patch does the following:
1. Move the infinite looping of CPUs which haven't called panic() in NMI
context (actually done by panic_smp_self_stop()) outside of panic() to
enable us to refer pt_regs. Please note that panic_smp_self_stop() is
still used for normal context.
2. Call a callback of kdump_nmi_shootdown_cpus() directly to save
registers and do some cleanups after setting waiting_for_crash_ipi which
is used for counting down the number of CPUs which handled the callback
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Aaron Tomlin <atomlin@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Gobinda Charan Maji <gobinda.cemk07@gmail.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: kexec@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: lkml <linux-kernel@vger.kernel.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Link: http://lkml.kernel.org/r/20151210014628.25437.75256.stgit@softrs
[ Cleanup comments, fixup formatting. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-12-14 10:19:10 +00:00
|
|
|
|
2015-12-14 10:19:13 +00:00
|
|
|
/*
|
|
|
|
* Check if the crash dumping IPI got issued and if so, call its callback
|
|
|
|
* directly. This function is used when we have already been in NMI handler.
|
|
|
|
* It doesn't return.
|
|
|
|
*/
|
|
|
|
void run_crash_ipi_callback(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
if (crash_ipi_issued)
|
|
|
|
crash_nmi_callback(0, regs);
|
|
|
|
}
|
|
|
|
|
panic, x86: Allow CPUs to save registers even if looping in NMI context
Currently, kdump_nmi_shootdown_cpus(), a subroutine of crash_kexec(),
sends an NMI IPI to CPUs which haven't called panic() to stop them,
save their register information and do some cleanups for crash dumping.
However, if such a CPU is infinitely looping in NMI context, we fail to
save its register information into the crash dump.
For example, this can happen when unknown NMIs are broadcast to all
CPUs as follows:
CPU 0 CPU 1
=========================== ==========================
receive an unknown NMI
unknown_nmi_error()
panic() receive an unknown NMI
spin_trylock(&panic_lock) unknown_nmi_error()
crash_kexec() panic()
spin_trylock(&panic_lock)
panic_smp_self_stop()
infinite loop
kdump_nmi_shootdown_cpus()
issue NMI IPI -----------> blocked until IRET
infinite loop...
Here, since CPU 1 is in NMI context, the second NMI from CPU 0 is
blocked until CPU 1 executes IRET. However, CPU 1 never executes IRET,
so the NMI is not handled and the callback function to save registers is
never called.
In practice, this can happen on some servers which broadcast NMIs to all
CPUs when the NMI button is pushed.
To save registers in this case, we need to:
a) Return from NMI handler instead of looping infinitely
or
b) Call the callback function directly from the infinite loop
Inherently, a) is risky because NMI is also used to prevent corrupted
data from being propagated to devices. So, we chose b).
This patch does the following:
1. Move the infinite looping of CPUs which haven't called panic() in NMI
context (actually done by panic_smp_self_stop()) outside of panic() to
enable us to refer pt_regs. Please note that panic_smp_self_stop() is
still used for normal context.
2. Call a callback of kdump_nmi_shootdown_cpus() directly to save
registers and do some cleanups after setting waiting_for_crash_ipi which
is used for counting down the number of CPUs which handled the callback
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Aaron Tomlin <atomlin@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Gobinda Charan Maji <gobinda.cemk07@gmail.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: kexec@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: lkml <linux-kernel@vger.kernel.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Link: http://lkml.kernel.org/r/20151210014628.25437.75256.stgit@softrs
[ Cleanup comments, fixup formatting. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-12-14 10:19:10 +00:00
|
|
|
/* Override the weak function in kernel/panic.c */
|
|
|
|
void nmi_panic_self_stop(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
while (1) {
|
2015-12-14 10:19:13 +00:00
|
|
|
/* If no CPU is preparing crash dump, we simply loop here. */
|
|
|
|
run_crash_ipi_callback(regs);
|
panic, x86: Allow CPUs to save registers even if looping in NMI context
Currently, kdump_nmi_shootdown_cpus(), a subroutine of crash_kexec(),
sends an NMI IPI to CPUs which haven't called panic() to stop them,
save their register information and do some cleanups for crash dumping.
However, if such a CPU is infinitely looping in NMI context, we fail to
save its register information into the crash dump.
For example, this can happen when unknown NMIs are broadcast to all
CPUs as follows:
CPU 0 CPU 1
=========================== ==========================
receive an unknown NMI
unknown_nmi_error()
panic() receive an unknown NMI
spin_trylock(&panic_lock) unknown_nmi_error()
crash_kexec() panic()
spin_trylock(&panic_lock)
panic_smp_self_stop()
infinite loop
kdump_nmi_shootdown_cpus()
issue NMI IPI -----------> blocked until IRET
infinite loop...
Here, since CPU 1 is in NMI context, the second NMI from CPU 0 is
blocked until CPU 1 executes IRET. However, CPU 1 never executes IRET,
so the NMI is not handled and the callback function to save registers is
never called.
In practice, this can happen on some servers which broadcast NMIs to all
CPUs when the NMI button is pushed.
To save registers in this case, we need to:
a) Return from NMI handler instead of looping infinitely
or
b) Call the callback function directly from the infinite loop
Inherently, a) is risky because NMI is also used to prevent corrupted
data from being propagated to devices. So, we chose b).
This patch does the following:
1. Move the infinite looping of CPUs which haven't called panic() in NMI
context (actually done by panic_smp_self_stop()) outside of panic() to
enable us to refer pt_regs. Please note that panic_smp_self_stop() is
still used for normal context.
2. Call a callback of kdump_nmi_shootdown_cpus() directly to save
registers and do some cleanups after setting waiting_for_crash_ipi which
is used for counting down the number of CPUs which handled the callback
Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Aaron Tomlin <atomlin@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Baoquan He <bhe@redhat.com>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Don Zickus <dzickus@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Gobinda Charan Maji <gobinda.cemk07@gmail.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Javi Merino <javi.merino@arm.com>
Cc: Jiang Liu <jiang.liu@linux.intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: kexec@lists.infradead.org
Cc: linux-doc@vger.kernel.org
Cc: lkml <linux-kernel@vger.kernel.org>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Michal Nazarewicz <mina86@mina86.com>
Cc: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Seth Jennings <sjenning@redhat.com>
Cc: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ulrich Obergfell <uobergfe@redhat.com>
Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Link: http://lkml.kernel.org/r/20151210014628.25437.75256.stgit@softrs
[ Cleanup comments, fixup formatting. ]
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2015-12-14 10:19:10 +00:00
|
|
|
cpu_relax();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-11-12 13:34:43 +00:00
|
|
|
#else /* !CONFIG_SMP */
|
|
|
|
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
|
|
|
|
{
|
|
|
|
/* No other CPUs to shoot down */
|
|
|
|
}
|
2015-12-14 10:19:13 +00:00
|
|
|
|
|
|
|
void run_crash_ipi_callback(struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
}
|
2008-11-12 13:34:42 +00:00
|
|
|
#endif
|