2019-05-27 14:55:21 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
/*
|
|
|
|
* APEI Generic Hardware Error Source support
|
|
|
|
*
|
|
|
|
* Generic Hardware Error Source provides a way to report platform
|
|
|
|
* hardware errors (such as that from chipset). It works in so called
|
|
|
|
* "Firmware First" mode, that is, hardware errors are reported to
|
|
|
|
* firmware firstly, then reported to Linux by firmware. This way,
|
|
|
|
* some non-standard hardware error registers or non-standard hardware
|
|
|
|
* link can be checked by firmware to produce more hardware error
|
|
|
|
* information for Linux.
|
|
|
|
*
|
|
|
|
* For more information about Generic Hardware Error Source, please
|
|
|
|
* refer to ACPI Specification version 4.0, section 17.3.2.6
|
|
|
|
*
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
* Copyright 2010,2011 Intel Corp.
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
* Author: Huang Ying <ying.huang@intel.com>
|
|
|
|
*/
|
|
|
|
|
2019-01-30 02:49:02 +08:00
|
|
|
#include <linux/arm_sdei.h>
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
#include <linux/kernel.h>
|
2016-02-15 13:27:50 +08:00
|
|
|
#include <linux/moduleparam.h>
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/io.h>
|
|
|
|
#include <linux/interrupt.h>
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
#include <linux/timer.h>
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
#include <linux/cper.h>
|
2010-08-02 15:48:24 +08:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/mutex.h>
|
2010-12-07 10:22:31 +08:00
|
|
|
#include <linux/ratelimit.h>
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
#include <linux/vmalloc.h>
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
#include <linux/irq_work.h>
|
|
|
|
#include <linux/llist.h>
|
|
|
|
#include <linux/genalloc.h>
|
2011-12-08 11:25:41 +08:00
|
|
|
#include <linux/pci.h>
|
2019-01-30 02:48:52 +08:00
|
|
|
#include <linux/pfn.h>
|
2011-12-08 11:25:41 +08:00
|
|
|
#include <linux/aer.h>
|
2014-07-22 17:20:12 +08:00
|
|
|
#include <linux/nmi.h>
|
2017-02-01 23:36:40 +08:00
|
|
|
#include <linux/sched/clock.h>
|
2017-06-22 02:17:12 +08:00
|
|
|
#include <linux/uuid.h>
|
|
|
|
#include <linux/ras.h>
|
2020-05-02 00:45:42 +08:00
|
|
|
#include <linux/task_work.h>
|
2013-02-15 16:41:22 +08:00
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
#include <acpi/actbl1.h>
|
2013-02-15 16:41:22 +08:00
|
|
|
#include <acpi/ghes.h>
|
2014-07-22 17:20:11 +08:00
|
|
|
#include <acpi/apei.h>
|
2017-11-07 02:44:24 +08:00
|
|
|
#include <asm/fixmap.h>
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
#include <asm/tlbflush.h>
|
2017-06-22 02:17:12 +08:00
|
|
|
#include <ras/ras_event.h>
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
|
|
|
#include "apei-internal.h"
|
|
|
|
|
|
|
|
#define GHES_PFX "GHES: "
|
|
|
|
|
|
|
|
#define GHES_ESTATUS_MAX_SIZE 65536
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
#define GHES_ESOURCE_PREALLOC_MAX_SIZE 65536
|
|
|
|
|
|
|
|
#define GHES_ESTATUS_POOL_MIN_ALLOC_ORDER 3
|
|
|
|
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
/* This is just an estimation for memory pool allocation */
|
|
|
|
#define GHES_ESTATUS_CACHE_AVG_SIZE 512
|
|
|
|
|
|
|
|
#define GHES_ESTATUS_CACHES_SIZE 4
|
|
|
|
|
2011-08-03 06:00:21 +08:00
|
|
|
#define GHES_ESTATUS_IN_CACHE_MAX_NSEC 10000000000ULL
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
/* Prevent too many caches are allocated because of RCU */
|
|
|
|
#define GHES_ESTATUS_CACHE_ALLOCED_MAX (GHES_ESTATUS_CACHES_SIZE * 3 / 2)
|
|
|
|
|
|
|
|
#define GHES_ESTATUS_CACHE_LEN(estatus_len) \
|
|
|
|
(sizeof(struct ghes_estatus_cache) + (estatus_len))
|
|
|
|
#define GHES_ESTATUS_FROM_CACHE(estatus_cache) \
|
2014-06-03 16:32:53 +08:00
|
|
|
((struct acpi_hest_generic_status *) \
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
((struct ghes_estatus_cache *)(estatus_cache) + 1))
|
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
#define GHES_ESTATUS_NODE_LEN(estatus_len) \
|
|
|
|
(sizeof(struct ghes_estatus_node) + (estatus_len))
|
2013-10-19 05:28:59 +08:00
|
|
|
#define GHES_ESTATUS_FROM_NODE(estatus_node) \
|
2014-06-03 16:32:53 +08:00
|
|
|
((struct acpi_hest_generic_status *) \
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
((struct ghes_estatus_node *)(estatus_node) + 1))
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2020-09-03 20:34:55 +08:00
|
|
|
#define GHES_VENDOR_ENTRY_LEN(gdata_len) \
|
|
|
|
(sizeof(struct ghes_vendor_record_entry) + (gdata_len))
|
|
|
|
#define GHES_GDATA_FROM_VENDOR_ENTRY(vendor_entry) \
|
|
|
|
((struct acpi_hest_generic_data *) \
|
|
|
|
((struct ghes_vendor_record_entry *)(vendor_entry) + 1))
|
|
|
|
|
2019-01-30 02:49:02 +08:00
|
|
|
/*
|
|
|
|
* NMI-like notifications vary by architecture, before the compiler can prune
|
|
|
|
* unused static functions it needs a value for these enums.
|
|
|
|
*/
|
|
|
|
#ifndef CONFIG_ARM_SDE_INTERFACE
|
|
|
|
#define FIX_APEI_GHES_SDEI_NORMAL __end_of_fixed_addresses
|
|
|
|
#define FIX_APEI_GHES_SDEI_CRITICAL __end_of_fixed_addresses
|
|
|
|
#endif
|
|
|
|
|
2022-10-10 10:35:54 +08:00
|
|
|
static ATOMIC_NOTIFIER_HEAD(ghes_report_chain);
|
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
static inline bool is_hest_type_generic_v2(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
return ghes->generic->header.type == ACPI_HEST_TYPE_GENERIC_ERROR_V2;
|
|
|
|
}
|
|
|
|
|
2016-02-15 13:27:50 +08:00
|
|
|
/*
|
|
|
|
* This driver isn't really modular, however for the time being,
|
|
|
|
* continuing to use module_param is the easiest way to remain
|
|
|
|
* compatible with existing boot arg use cases.
|
|
|
|
*/
|
2012-01-13 07:02:20 +08:00
|
|
|
bool ghes_disable;
|
2011-07-13 13:14:19 +08:00
|
|
|
module_param_named(disable, ghes_disable, bool, 0);
|
|
|
|
|
2022-10-10 10:35:55 +08:00
|
|
|
/*
|
|
|
|
* "ghes.edac_force_enable" forcibly enables ghes_edac and skips the platform
|
|
|
|
* check.
|
|
|
|
*/
|
|
|
|
static bool ghes_edac_force_enable;
|
|
|
|
module_param_named(edac_force_enable, ghes_edac_force_enable, bool, 0);
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
/*
|
2017-05-19 17:39:11 +08:00
|
|
|
* All error sources notified with HED (Hardware Error Device) share a
|
|
|
|
* single notifier callback, so they need to be linked and checked one
|
|
|
|
* by one. This holds true for NMI too.
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
*
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
* RCU is used for these lists, so ghes_list_mutex is only used for
|
|
|
|
* list changing, not for traversing.
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
*/
|
2017-05-19 17:39:11 +08:00
|
|
|
static LIST_HEAD(ghes_hed);
|
2010-08-02 15:48:24 +08:00
|
|
|
static DEFINE_MUTEX(ghes_list_mutex);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2022-10-10 10:35:55 +08:00
|
|
|
/*
|
|
|
|
* A list of GHES devices which are given to the corresponding EDAC driver
|
|
|
|
* ghes_edac for further use.
|
|
|
|
*/
|
|
|
|
static LIST_HEAD(ghes_devs);
|
|
|
|
static DEFINE_MUTEX(ghes_devs_mutex);
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
/*
|
|
|
|
* Because the memory area used to transfer hardware error information
|
|
|
|
* from BIOS to Linux can be determined only in NMI, IRQ or timer
|
|
|
|
* handler, but general ioremap can not be used in atomic context, so
|
2017-11-07 02:44:24 +08:00
|
|
|
* the fixmap is used instead.
|
2017-11-07 02:44:25 +08:00
|
|
|
*
|
2019-01-30 02:48:51 +08:00
|
|
|
* This spinlock is used to prevent the fixmap entry from being used
|
2017-11-07 02:44:24 +08:00
|
|
|
* simultaneously.
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
*/
|
2019-01-30 02:48:51 +08:00
|
|
|
static DEFINE_SPINLOCK(ghes_notify_lock_irq);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
2020-09-03 20:34:55 +08:00
|
|
|
struct ghes_vendor_record_entry {
|
|
|
|
struct work_struct work;
|
|
|
|
int error_severity;
|
|
|
|
char vendor_record[];
|
|
|
|
};
|
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
static struct gen_pool *ghes_estatus_pool;
|
|
|
|
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
static struct ghes_estatus_cache __rcu *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE];
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
static atomic_t ghes_estatus_cache_alloced;
|
|
|
|
|
2017-06-22 02:17:10 +08:00
|
|
|
static int ghes_panic_timeout __read_mostly = 30;
|
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
static void __iomem *ghes_map(u64 pfn, enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
{
|
2017-06-22 02:17:09 +08:00
|
|
|
phys_addr_t paddr;
|
|
|
|
pgprot_t prot;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
paddr = PFN_PHYS(pfn);
|
2017-06-22 02:17:09 +08:00
|
|
|
prot = arch_apei_get_mem_attribute(paddr);
|
2019-01-30 02:48:52 +08:00
|
|
|
__set_fixmap(fixmap_idx, paddr, prot);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
return (void __iomem *) __fix_to_virt(fixmap_idx);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
static void ghes_unmap(void __iomem *vaddr, enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
{
|
2019-01-30 02:48:52 +08:00
|
|
|
int _idx = virt_to_fix((unsigned long)vaddr);
|
acpi/apei: Use appropriate pgprot_t to map GHES memory
If the ACPI APEI firmware handles hardware error first (called
"firmware first handling"), the firmware updates the GHES memory
region with hardware error record (called "generic hardware
error record"). Essentially the firmware writes hardware error
records in the GHES memory region, triggers an NMI/interrupt,
then the GHES driver goes off and grabs the error record from
the GHES region.
The kernel currently maps the GHES memory region as cacheable
(PAGE_KERNEL) for all architectures. However, on some arm64
platforms, there is a mismatch between how the kernel maps the
GHES region (PAGE_KERNEL) and how the firmware maps it
(EFI_MEMORY_UC, ie. uncacheable), leading to the possibility of
the kernel GHES driver reading stale data from the cache when it
receives the interrupt.
With stale data being read, the kernel is unaware there is new
hardware error to be handled when there actually is; this may
lead to further damage in various scenarios, such as error
propagation caused data corruption. If uncorrected error (such
as double bit ECC error) happened in memory operation and if the
kernel is unaware of such an event happening, errorneous data may
be propagated to the disk.
Instead GHES memory region should be mapped with page protection
type according to what is returned from arch_apei_get_mem_attribute().
Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
[ Small stylistic tweaks. ]
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1441372302-23242-3-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-04 21:11:42 +08:00
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
WARN_ON_ONCE(fixmap_idx != _idx);
|
|
|
|
clear_fixmap(fixmap_idx);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
|
|
|
|
2022-10-06 00:32:53 +08:00
|
|
|
int ghes_estatus_pool_init(unsigned int num_ghes)
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
{
|
2019-01-30 02:48:41 +08:00
|
|
|
unsigned long addr, len;
|
2019-07-15 14:58:44 +08:00
|
|
|
int rc;
|
2019-01-30 02:48:41 +08:00
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
ghes_estatus_pool = gen_pool_create(GHES_ESTATUS_POOL_MIN_ALLOC_ORDER, -1);
|
|
|
|
if (!ghes_estatus_pool)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-01-30 02:48:41 +08:00
|
|
|
len = GHES_ESTATUS_CACHE_AVG_SIZE * GHES_ESTATUS_CACHE_ALLOCED_MAX;
|
|
|
|
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
|
2019-01-30 02:48:39 +08:00
|
|
|
addr = (unsigned long)vmalloc(PAGE_ALIGN(len));
|
|
|
|
if (!addr)
|
2019-07-15 14:58:44 +08:00
|
|
|
goto err_pool_alloc;
|
2019-01-30 02:48:39 +08:00
|
|
|
|
2019-07-15 14:58:44 +08:00
|
|
|
rc = gen_pool_add(ghes_estatus_pool, addr, PAGE_ALIGN(len), -1);
|
|
|
|
if (rc)
|
|
|
|
goto err_pool_add;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_pool_add:
|
|
|
|
vfree((void *)addr);
|
|
|
|
|
|
|
|
err_pool_alloc:
|
|
|
|
gen_pool_destroy(ghes_estatus_pool);
|
|
|
|
|
|
|
|
return -ENOMEM;
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
}
|
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
static int map_gen_v2(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
return apei_map_generic_address(&ghes->generic_v2->read_ack_register);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unmap_gen_v2(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
apei_unmap_generic_address(&ghes->generic_v2->read_ack_register);
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:46 +08:00
|
|
|
static void ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
u64 val = 0;
|
|
|
|
|
|
|
|
rc = apei_read(&val, &gv2->read_ack_register);
|
|
|
|
if (rc)
|
|
|
|
return;
|
|
|
|
|
|
|
|
val &= gv2->read_ack_preserve << gv2->read_ack_register.bit_offset;
|
|
|
|
val |= gv2->read_ack_write << gv2->read_ack_register.bit_offset;
|
|
|
|
|
|
|
|
apei_write(val, &gv2->read_ack_register);
|
|
|
|
}
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
static struct ghes *ghes_new(struct acpi_hest_generic *generic)
|
|
|
|
{
|
|
|
|
struct ghes *ghes;
|
|
|
|
unsigned int error_block_length;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
ghes = kzalloc(sizeof(*ghes), GFP_KERNEL);
|
|
|
|
if (!ghes)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
2017-06-22 02:17:04 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
ghes->generic = generic;
|
2017-06-22 02:17:04 +08:00
|
|
|
if (is_hest_type_generic_v2(ghes)) {
|
|
|
|
rc = map_gen_v2(ghes);
|
|
|
|
if (rc)
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
2012-06-12 11:20:19 +08:00
|
|
|
rc = apei_map_generic_address(&generic->error_status_address);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (rc)
|
2017-06-22 02:17:04 +08:00
|
|
|
goto err_unmap_read_ack_addr;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
error_block_length = generic->error_block_length;
|
|
|
|
if (error_block_length > GHES_ESTATUS_MAX_SIZE) {
|
2019-10-18 11:18:25 +08:00
|
|
|
pr_warn(FW_WARN GHES_PFX
|
|
|
|
"Error status block length is too long: %u for "
|
|
|
|
"generic hardware error source: %d.\n",
|
|
|
|
error_block_length, generic->header.source_id);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
error_block_length = GHES_ESTATUS_MAX_SIZE;
|
|
|
|
}
|
|
|
|
ghes->estatus = kmalloc(error_block_length, GFP_KERNEL);
|
|
|
|
if (!ghes->estatus) {
|
|
|
|
rc = -ENOMEM;
|
2017-06-22 02:17:04 +08:00
|
|
|
goto err_unmap_status_addr;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return ghes;
|
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
err_unmap_status_addr:
|
2012-06-12 11:20:19 +08:00
|
|
|
apei_unmap_generic_address(&generic->error_status_address);
|
2017-06-22 02:17:04 +08:00
|
|
|
err_unmap_read_ack_addr:
|
|
|
|
if (is_hest_type_generic_v2(ghes))
|
|
|
|
unmap_gen_v2(ghes);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
err_free:
|
|
|
|
kfree(ghes);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_fini(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
kfree(ghes->estatus);
|
2012-06-12 11:20:19 +08:00
|
|
|
apei_unmap_generic_address(&ghes->generic->error_status_address);
|
2017-06-22 02:17:04 +08:00
|
|
|
if (is_hest_type_generic_v2(ghes))
|
|
|
|
unmap_gen_v2(ghes);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int ghes_severity(int severity)
|
|
|
|
{
|
|
|
|
switch (severity) {
|
2010-08-02 15:48:23 +08:00
|
|
|
case CPER_SEV_INFORMATIONAL:
|
|
|
|
return GHES_SEV_NO;
|
|
|
|
case CPER_SEV_CORRECTED:
|
|
|
|
return GHES_SEV_CORRECTED;
|
|
|
|
case CPER_SEV_RECOVERABLE:
|
|
|
|
return GHES_SEV_RECOVERABLE;
|
|
|
|
case CPER_SEV_FATAL:
|
|
|
|
return GHES_SEV_PANIC;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
default:
|
2011-03-31 09:57:33 +08:00
|
|
|
/* Unknown, go panic */
|
2010-08-02 15:48:23 +08:00
|
|
|
return GHES_SEV_PANIC;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
|
2019-01-30 02:48:52 +08:00
|
|
|
int from_phys,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
void __iomem *vaddr;
|
|
|
|
u64 offset;
|
|
|
|
u32 trunk;
|
|
|
|
|
|
|
|
while (len > 0) {
|
|
|
|
offset = paddr - (paddr & PAGE_MASK);
|
2019-01-30 02:48:52 +08:00
|
|
|
vaddr = ghes_map(PHYS_PFN(paddr), fixmap_idx);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
trunk = PAGE_SIZE - offset;
|
|
|
|
trunk = min(trunk, len);
|
|
|
|
if (from_phys)
|
|
|
|
memcpy_fromio(buffer, vaddr + offset, trunk);
|
|
|
|
else
|
|
|
|
memcpy_toio(vaddr + offset, buffer, trunk);
|
|
|
|
len -= trunk;
|
|
|
|
paddr += trunk;
|
|
|
|
buffer += trunk;
|
2019-01-30 02:48:52 +08:00
|
|
|
ghes_unmap(vaddr, fixmap_idx);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:54 +08:00
|
|
|
/* Check the top-level record header has an appropriate size. */
|
|
|
|
static int __ghes_check_estatus(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus)
|
|
|
|
{
|
|
|
|
u32 len = cper_estatus_len(estatus);
|
|
|
|
|
|
|
|
if (len < sizeof(*estatus)) {
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX "Truncated error status block!\n");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (len > ghes->generic->error_block_length) {
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid error status block length!\n");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cper_estatus_check_header(estatus)) {
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid CPER header!\n");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:55 +08:00
|
|
|
/* Read the CPER block, returning its address, and header in estatus. */
|
|
|
|
static int __ghes_peek_estatus(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 *buf_paddr, enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
|
|
|
struct acpi_hest_generic *g = ghes->generic;
|
|
|
|
int rc;
|
|
|
|
|
2019-01-30 02:48:42 +08:00
|
|
|
rc = apei_read(buf_paddr, &g->error_status_address);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (rc) {
|
2019-01-30 02:48:42 +08:00
|
|
|
*buf_paddr = 0;
|
2019-01-30 02:48:38 +08:00
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
"Failed to read error status block address for hardware error source: %d.\n",
|
|
|
|
g->header.source_id);
|
|
|
|
return -EIO;
|
|
|
|
}
|
2019-01-30 02:48:42 +08:00
|
|
|
if (!*buf_paddr)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
return -ENOENT;
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_copy_tofrom_phys(estatus, *buf_paddr, sizeof(*estatus), 1,
|
|
|
|
fixmap_idx);
|
|
|
|
if (!estatus->block_status) {
|
2019-01-30 02:48:42 +08:00
|
|
|
*buf_paddr = 0;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
return -ENOENT;
|
2019-01-30 02:48:42 +08:00
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2019-06-25 13:15:28 +08:00
|
|
|
return 0;
|
2019-01-30 02:48:55 +08:00
|
|
|
}
|
2019-01-30 02:48:54 +08:00
|
|
|
|
2019-01-30 02:48:55 +08:00
|
|
|
static int __ghes_read_estatus(struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 buf_paddr, enum fixed_addresses fixmap_idx,
|
|
|
|
size_t buf_len)
|
|
|
|
{
|
|
|
|
ghes_copy_tofrom_phys(estatus, buf_paddr, buf_len, 1, fixmap_idx);
|
2019-01-30 02:48:54 +08:00
|
|
|
if (cper_estatus_check(estatus)) {
|
2019-01-30 02:48:38 +08:00
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
|
|
|
"Failed to read error status block!\n");
|
2019-01-30 02:48:54 +08:00
|
|
|
return -EIO;
|
|
|
|
}
|
2019-01-30 02:48:42 +08:00
|
|
|
|
2019-01-30 02:48:54 +08:00
|
|
|
return 0;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:55 +08:00
|
|
|
static int ghes_read_estatus(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 *buf_paddr, enum fixed_addresses fixmap_idx)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = __ghes_peek_estatus(ghes, estatus, buf_paddr, fixmap_idx);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
rc = __ghes_check_estatus(ghes, estatus);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
return __ghes_read_estatus(estatus, *buf_paddr, fixmap_idx,
|
|
|
|
cper_estatus_len(estatus));
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
static void ghes_clear_estatus(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 buf_paddr, enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
2019-01-30 02:48:53 +08:00
|
|
|
estatus->block_status = 0;
|
2019-01-30 02:48:42 +08:00
|
|
|
|
|
|
|
if (!buf_paddr)
|
|
|
|
return;
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_copy_tofrom_phys(estatus, buf_paddr,
|
|
|
|
sizeof(estatus->block_status), 0,
|
2019-01-30 02:48:52 +08:00
|
|
|
fixmap_idx);
|
2019-01-30 02:48:46 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* GHESv2 type HEST entries introduce support for error acknowledgment,
|
|
|
|
* so only acknowledge the error if this support is present.
|
|
|
|
*/
|
|
|
|
if (is_hest_type_generic_v2(ghes))
|
|
|
|
ghes_ack_error(ghes->generic_v2);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2020-05-02 00:45:42 +08:00
|
|
|
/*
|
|
|
|
* Called as task_work before returning to user-space.
|
|
|
|
* Ensure any queued work has been done before we return to the context that
|
|
|
|
* triggered the notification.
|
|
|
|
*/
|
|
|
|
static void ghes_kick_task_work(struct callback_head *head)
|
|
|
|
{
|
|
|
|
struct acpi_hest_generic_status *estatus;
|
|
|
|
struct ghes_estatus_node *estatus_node;
|
|
|
|
u32 node_len;
|
|
|
|
|
|
|
|
estatus_node = container_of(head, struct ghes_estatus_node, task_work);
|
|
|
|
if (IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE))
|
|
|
|
memory_failure_queue_kick(estatus_node->task_work_cpu);
|
|
|
|
|
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(cper_estatus_len(estatus));
|
|
|
|
gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node, node_len);
|
|
|
|
}
|
|
|
|
|
2021-06-11 20:37:07 +08:00
|
|
|
static bool ghes_do_memory_failure(u64 physical_addr, int flags)
|
2013-07-10 17:27:01 +08:00
|
|
|
{
|
|
|
|
unsigned long pfn;
|
|
|
|
|
2020-05-02 00:45:42 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE))
|
|
|
|
return false;
|
|
|
|
|
2021-06-11 20:37:07 +08:00
|
|
|
pfn = PHYS_PFN(physical_addr);
|
2021-10-27 06:00:50 +08:00
|
|
|
if (!pfn_valid(pfn) && !arch_is_platform_page(physical_addr)) {
|
2013-11-25 15:15:01 +08:00
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
|
|
|
"Invalid address in generic error data: %#llx\n",
|
2021-06-11 20:37:07 +08:00
|
|
|
physical_addr);
|
2020-05-02 00:45:42 +08:00
|
|
|
return false;
|
2013-07-10 17:27:01 +08:00
|
|
|
}
|
2013-11-25 15:15:01 +08:00
|
|
|
|
2021-06-11 20:37:07 +08:00
|
|
|
memory_failure_queue(pfn, flags);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata,
|
|
|
|
int sev)
|
|
|
|
{
|
|
|
|
int flags = -1;
|
|
|
|
int sec_sev = ghes_severity(gdata->error_severity);
|
|
|
|
struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata);
|
|
|
|
|
|
|
|
if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
|
|
|
|
return false;
|
|
|
|
|
2013-11-25 15:15:01 +08:00
|
|
|
/* iff following two events can be handled properly by now */
|
|
|
|
if (sec_sev == GHES_SEV_CORRECTED &&
|
|
|
|
(gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED))
|
|
|
|
flags = MF_SOFT_OFFLINE;
|
|
|
|
if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE)
|
|
|
|
flags = 0;
|
|
|
|
|
2021-06-11 20:37:07 +08:00
|
|
|
if (flags != -1)
|
|
|
|
return ghes_do_memory_failure(mem_err->physical_addr, flags);
|
2020-05-02 00:45:42 +08:00
|
|
|
|
|
|
|
return false;
|
2013-07-10 17:27:01 +08:00
|
|
|
}
|
|
|
|
|
2021-06-11 20:37:07 +08:00
|
|
|
static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata, int sev)
|
|
|
|
{
|
|
|
|
struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata);
|
|
|
|
bool queued = false;
|
|
|
|
int sec_sev, i;
|
|
|
|
char *p;
|
|
|
|
|
|
|
|
log_arm_hw_error(err);
|
|
|
|
|
|
|
|
sec_sev = ghes_severity(gdata->error_severity);
|
|
|
|
if (sev != GHES_SEV_RECOVERABLE || sec_sev != GHES_SEV_RECOVERABLE)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
p = (char *)(err + 1);
|
|
|
|
for (i = 0; i < err->err_info_num; i++) {
|
|
|
|
struct cper_arm_err_info *err_info = (struct cper_arm_err_info *)p;
|
|
|
|
bool is_cache = (err_info->type == CPER_ARM_CACHE_ERROR);
|
|
|
|
bool has_pa = (err_info->validation_bits & CPER_ARM_INFO_VALID_PHYSICAL_ADDR);
|
|
|
|
const char *error_type = "unknown error";
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The field (err_info->error_info & BIT(26)) is fixed to set to
|
|
|
|
* 1 in some old firmware of HiSilicon Kunpeng920. We assume that
|
|
|
|
* firmware won't mix corrected errors in an uncorrected section,
|
|
|
|
* and don't filter out 'corrected' error here.
|
|
|
|
*/
|
|
|
|
if (is_cache && has_pa) {
|
|
|
|
queued = ghes_do_memory_failure(err_info->physical_fault_addr, 0);
|
|
|
|
p += err_info->length;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (err_info->type < ARRAY_SIZE(cper_proc_error_type_strs))
|
|
|
|
error_type = cper_proc_error_type_strs[err_info->type];
|
|
|
|
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
|
|
|
"Unhandled processor error type: %s\n",
|
|
|
|
error_type);
|
|
|
|
p += err_info->length;
|
|
|
|
}
|
|
|
|
|
|
|
|
return queued;
|
|
|
|
}
|
|
|
|
|
2017-11-29 05:48:09 +08:00
|
|
|
/*
|
|
|
|
* PCIe AER errors need to be sent to the AER driver for reporting and
|
|
|
|
* recovery. The GHES severities map to the following AER severities and
|
|
|
|
* require the following handling:
|
|
|
|
*
|
|
|
|
* GHES_SEV_CORRECTABLE -> AER_CORRECTABLE
|
|
|
|
* These need to be reported by the AER driver but no recovery is
|
|
|
|
* necessary.
|
|
|
|
* GHES_SEV_RECOVERABLE -> AER_NONFATAL
|
|
|
|
* GHES_SEV_RECOVERABLE && CPER_SEC_RESET -> AER_FATAL
|
|
|
|
* These both need to be reported and recovered from by the AER driver.
|
|
|
|
* GHES_SEV_PANIC does not make it to this handling since the kernel must
|
|
|
|
* panic.
|
|
|
|
*/
|
|
|
|
static void ghes_handle_aer(struct acpi_hest_generic_data *gdata)
|
2017-11-29 05:48:08 +08:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_ACPI_APEI_PCIEAER
|
|
|
|
struct cper_sec_pcie *pcie_err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2017-11-29 05:48:09 +08:00
|
|
|
if (pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
|
2017-11-29 05:48:08 +08:00
|
|
|
pcie_err->validation_bits & CPER_PCIE_VALID_AER_INFO) {
|
|
|
|
unsigned int devfn;
|
|
|
|
int aer_severity;
|
|
|
|
|
|
|
|
devfn = PCI_DEVFN(pcie_err->device_id.device,
|
|
|
|
pcie_err->device_id.function);
|
|
|
|
aer_severity = cper_severity_to_aer(gdata->error_severity);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If firmware reset the component to contain
|
|
|
|
* the error, we must reinitialize it before
|
|
|
|
* use, so treat it as a fatal AER error.
|
|
|
|
*/
|
|
|
|
if (gdata->flags & CPER_SEC_RESET)
|
|
|
|
aer_severity = AER_FATAL;
|
|
|
|
|
|
|
|
aer_recover_queue(pcie_err->device_id.segment,
|
|
|
|
pcie_err->device_id.bus,
|
|
|
|
devfn, aer_severity,
|
|
|
|
(struct aer_capability_regs *)
|
|
|
|
pcie_err->aer_info);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2020-09-03 20:34:55 +08:00
|
|
|
static BLOCKING_NOTIFIER_HEAD(vendor_record_notify_list);
|
|
|
|
|
|
|
|
int ghes_register_vendor_record_notifier(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
return blocking_notifier_chain_register(&vendor_record_notify_list, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ghes_register_vendor_record_notifier);
|
|
|
|
|
|
|
|
void ghes_unregister_vendor_record_notifier(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
blocking_notifier_chain_unregister(&vendor_record_notify_list, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ghes_unregister_vendor_record_notifier);
|
|
|
|
|
|
|
|
static void ghes_vendor_record_work_func(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct ghes_vendor_record_entry *entry;
|
|
|
|
struct acpi_hest_generic_data *gdata;
|
|
|
|
u32 len;
|
|
|
|
|
|
|
|
entry = container_of(work, struct ghes_vendor_record_entry, work);
|
|
|
|
gdata = GHES_GDATA_FROM_VENDOR_ENTRY(entry);
|
|
|
|
|
|
|
|
blocking_notifier_call_chain(&vendor_record_notify_list,
|
|
|
|
entry->error_severity, gdata);
|
|
|
|
|
|
|
|
len = GHES_VENDOR_ENTRY_LEN(acpi_hest_get_record_size(gdata));
|
|
|
|
gen_pool_free(ghes_estatus_pool, (unsigned long)entry, len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_defer_non_standard_event(struct acpi_hest_generic_data *gdata,
|
|
|
|
int sev)
|
|
|
|
{
|
|
|
|
struct acpi_hest_generic_data *copied_gdata;
|
|
|
|
struct ghes_vendor_record_entry *entry;
|
|
|
|
u32 len;
|
|
|
|
|
|
|
|
len = GHES_VENDOR_ENTRY_LEN(acpi_hest_get_record_size(gdata));
|
|
|
|
entry = (void *)gen_pool_alloc(ghes_estatus_pool, len);
|
|
|
|
if (!entry)
|
|
|
|
return;
|
|
|
|
|
|
|
|
copied_gdata = GHES_GDATA_FROM_VENDOR_ENTRY(entry);
|
|
|
|
memcpy(copied_gdata, gdata, acpi_hest_get_record_size(gdata));
|
|
|
|
entry->error_severity = sev;
|
|
|
|
|
|
|
|
INIT_WORK(&entry->work, ghes_vendor_record_work_func);
|
|
|
|
schedule_work(&entry->work);
|
|
|
|
}
|
|
|
|
|
2020-05-02 00:45:42 +08:00
|
|
|
static bool ghes_do_proc(struct ghes *ghes,
|
2014-06-03 16:32:53 +08:00
|
|
|
const struct acpi_hest_generic_status *estatus)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
2011-07-13 13:14:28 +08:00
|
|
|
int sev, sec_sev;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_data *gdata;
|
2017-06-06 00:40:43 +08:00
|
|
|
guid_t *sec_type;
|
2019-07-17 18:55:43 +08:00
|
|
|
const guid_t *fru_id = &guid_null;
|
2017-06-22 02:17:12 +08:00
|
|
|
char *fru_text = "";
|
2020-05-02 00:45:42 +08:00
|
|
|
bool queued = false;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
sev = ghes_severity(estatus->error_severity);
|
|
|
|
apei_estatus_for_each_section(estatus, gdata) {
|
2017-06-06 00:40:43 +08:00
|
|
|
sec_type = (guid_t *)gdata->section_type;
|
2011-07-13 13:14:28 +08:00
|
|
|
sec_sev = ghes_severity(gdata->error_severity);
|
2017-06-22 02:17:12 +08:00
|
|
|
if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
|
|
|
|
fru_id = (guid_t *)gdata->fru_id;
|
|
|
|
|
|
|
|
if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
|
|
|
|
fru_text = gdata->fru_text;
|
|
|
|
|
2017-06-06 00:40:43 +08:00
|
|
|
if (guid_equal(sec_type, &CPER_SEC_PLATFORM_MEM)) {
|
2017-06-22 02:17:05 +08:00
|
|
|
struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2022-10-10 10:35:54 +08:00
|
|
|
atomic_notifier_call_chain(&ghes_report_chain, sev, mem_err);
|
2013-02-15 17:10:39 +08:00
|
|
|
|
2014-07-22 17:20:11 +08:00
|
|
|
arch_apei_report_mem_error(sev, mem_err);
|
2020-05-02 00:45:42 +08:00
|
|
|
queued = ghes_handle_memory_failure(gdata, sev);
|
2011-07-13 13:14:28 +08:00
|
|
|
}
|
2017-06-06 00:40:43 +08:00
|
|
|
else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
|
2017-11-29 05:48:09 +08:00
|
|
|
ghes_handle_aer(gdata);
|
2011-12-08 11:25:41 +08:00
|
|
|
}
|
2017-06-22 02:17:13 +08:00
|
|
|
else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
|
2021-06-11 20:37:07 +08:00
|
|
|
queued = ghes_handle_arm_hw_error(gdata, sev);
|
2017-06-22 02:17:13 +08:00
|
|
|
} else {
|
2017-06-22 02:17:12 +08:00
|
|
|
void *err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2020-09-03 20:34:55 +08:00
|
|
|
ghes_defer_non_standard_event(gdata, sev);
|
2017-06-22 02:17:12 +08:00
|
|
|
log_non_standard_event(sec_type, fru_id, fru_text,
|
|
|
|
sec_sev, err,
|
|
|
|
gdata->error_data_length);
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
2020-05-02 00:45:42 +08:00
|
|
|
|
|
|
|
return queued;
|
2010-12-07 10:22:31 +08:00
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
static void __ghes_print_estatus(const char *pfx,
|
|
|
|
const struct acpi_hest_generic *generic,
|
2014-06-03 16:32:53 +08:00
|
|
|
const struct acpi_hest_generic_status *estatus)
|
2010-12-07 10:22:31 +08:00
|
|
|
{
|
2011-12-08 11:25:44 +08:00
|
|
|
static atomic_t seqno;
|
|
|
|
unsigned int curr_seqno;
|
|
|
|
char pfx_seq[64];
|
|
|
|
|
2010-12-07 10:22:31 +08:00
|
|
|
if (pfx == NULL) {
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
if (ghes_severity(estatus->error_severity) <=
|
2010-12-07 10:22:31 +08:00
|
|
|
GHES_SEV_CORRECTED)
|
2011-12-08 11:25:44 +08:00
|
|
|
pfx = KERN_WARNING;
|
2010-12-07 10:22:31 +08:00
|
|
|
else
|
2011-12-08 11:25:44 +08:00
|
|
|
pfx = KERN_ERR;
|
2010-12-07 10:22:31 +08:00
|
|
|
}
|
2011-12-08 11:25:44 +08:00
|
|
|
curr_seqno = atomic_inc_return(&seqno);
|
|
|
|
snprintf(pfx_seq, sizeof(pfx_seq), "%s{%u}" HW_ERR, pfx, curr_seqno);
|
2011-07-13 13:14:15 +08:00
|
|
|
printk("%s""Hardware error from APEI Generic Hardware Error Source: %d\n",
|
2011-12-08 11:25:44 +08:00
|
|
|
pfx_seq, generic->header.source_id);
|
2013-10-19 05:28:59 +08:00
|
|
|
cper_estatus_print(pfx_seq, estatus);
|
2011-07-13 13:14:15 +08:00
|
|
|
}
|
|
|
|
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
static int ghes_print_estatus(const char *pfx,
|
|
|
|
const struct acpi_hest_generic *generic,
|
2014-06-03 16:32:53 +08:00
|
|
|
const struct acpi_hest_generic_status *estatus)
|
2011-07-13 13:14:15 +08:00
|
|
|
{
|
|
|
|
/* Not more than 2 messages every 5 seconds */
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
static DEFINE_RATELIMIT_STATE(ratelimit_corrected, 5*HZ, 2);
|
|
|
|
static DEFINE_RATELIMIT_STATE(ratelimit_uncorrected, 5*HZ, 2);
|
|
|
|
struct ratelimit_state *ratelimit;
|
2011-07-13 13:14:15 +08:00
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
if (ghes_severity(estatus->error_severity) <= GHES_SEV_CORRECTED)
|
|
|
|
ratelimit = &ratelimit_corrected;
|
|
|
|
else
|
|
|
|
ratelimit = &ratelimit_uncorrected;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
if (__ratelimit(ratelimit)) {
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
__ghes_print_estatus(pfx, generic, estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GHES error status reporting throttle, to report more kinds of
|
|
|
|
* errors, instead of just most frequently occurred errors.
|
|
|
|
*/
|
2014-06-03 16:32:53 +08:00
|
|
|
static int ghes_estatus_cached(struct acpi_hest_generic_status *estatus)
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
{
|
|
|
|
u32 len;
|
|
|
|
int i, cached = 0;
|
|
|
|
unsigned long long now;
|
|
|
|
struct ghes_estatus_cache *cache;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *cache_estatus;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
for (i = 0; i < GHES_ESTATUS_CACHES_SIZE; i++) {
|
|
|
|
cache = rcu_dereference(ghes_estatus_caches[i]);
|
|
|
|
if (cache == NULL)
|
|
|
|
continue;
|
|
|
|
if (len != cache->estatus_len)
|
|
|
|
continue;
|
|
|
|
cache_estatus = GHES_ESTATUS_FROM_CACHE(cache);
|
|
|
|
if (memcmp(estatus, cache_estatus, len))
|
|
|
|
continue;
|
|
|
|
atomic_inc(&cache->count);
|
|
|
|
now = sched_clock();
|
|
|
|
if (now - cache->time_in < GHES_ESTATUS_IN_CACHE_MAX_NSEC)
|
|
|
|
cached = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
return cached;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct ghes_estatus_cache *ghes_estatus_cache_alloc(
|
|
|
|
struct acpi_hest_generic *generic,
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus)
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
{
|
|
|
|
int alloced;
|
|
|
|
u32 len, cache_len;
|
|
|
|
struct ghes_estatus_cache *cache;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *cache_estatus;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
|
|
|
|
alloced = atomic_add_return(1, &ghes_estatus_cache_alloced);
|
|
|
|
if (alloced > GHES_ESTATUS_CACHE_ALLOCED_MAX) {
|
|
|
|
atomic_dec(&ghes_estatus_cache_alloced);
|
|
|
|
return NULL;
|
|
|
|
}
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
cache_len = GHES_ESTATUS_CACHE_LEN(len);
|
|
|
|
cache = (void *)gen_pool_alloc(ghes_estatus_pool, cache_len);
|
|
|
|
if (!cache) {
|
|
|
|
atomic_dec(&ghes_estatus_cache_alloced);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
cache_estatus = GHES_ESTATUS_FROM_CACHE(cache);
|
|
|
|
memcpy(cache_estatus, estatus, len);
|
|
|
|
cache->estatus_len = len;
|
|
|
|
atomic_set(&cache->count, 0);
|
|
|
|
cache->generic = generic;
|
|
|
|
cache->time_in = sched_clock();
|
|
|
|
return cache;
|
|
|
|
}
|
|
|
|
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
static void ghes_estatus_cache_rcu_free(struct rcu_head *head)
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
{
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
struct ghes_estatus_cache *cache;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
u32 len;
|
|
|
|
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
cache = container_of(head, struct ghes_estatus_cache, rcu);
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(GHES_ESTATUS_FROM_CACHE(cache));
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
len = GHES_ESTATUS_CACHE_LEN(len);
|
|
|
|
gen_pool_free(ghes_estatus_pool, (unsigned long)cache, len);
|
|
|
|
atomic_dec(&ghes_estatus_cache_alloced);
|
|
|
|
}
|
|
|
|
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
static void
|
|
|
|
ghes_estatus_cache_add(struct acpi_hest_generic *generic,
|
|
|
|
struct acpi_hest_generic_status *estatus)
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
{
|
|
|
|
unsigned long long now, duration, period, max_period = 0;
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
struct ghes_estatus_cache *cache, *new_cache;
|
|
|
|
struct ghes_estatus_cache __rcu *victim;
|
|
|
|
int i, slot = -1, count;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
|
|
|
|
new_cache = ghes_estatus_cache_alloc(generic, estatus);
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
if (!new_cache)
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
return;
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
now = sched_clock();
|
|
|
|
for (i = 0; i < GHES_ESTATUS_CACHES_SIZE; i++) {
|
|
|
|
cache = rcu_dereference(ghes_estatus_caches[i]);
|
|
|
|
if (cache == NULL) {
|
|
|
|
slot = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
duration = now - cache->time_in;
|
|
|
|
if (duration >= GHES_ESTATUS_IN_CACHE_MAX_NSEC) {
|
|
|
|
slot = i;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
count = atomic_read(&cache->count);
|
2011-08-03 06:00:21 +08:00
|
|
|
period = duration;
|
|
|
|
do_div(period, (count + 1));
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
if (period > max_period) {
|
|
|
|
max_period = period;
|
|
|
|
slot = i;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
apei/ghes: Use xchg_release() for updating new cache slot instead of cmpxchg()
Some documentation first, about how this machinery works:
It seems, the intent of the GHES error records cache is to collect
already reported errors - see the ghes_estatus_cached() checks. There's
even a sentence trying to say what this does:
/*
* GHES error status reporting throttle, to report more kinds of
* errors, instead of just most frequently occurred errors.
*/
New elements are added to the cache this way:
if (!ghes_estatus_cached(estatus)) {
if (ghes_print_estatus(NULL, ghes->generic, estatus))
ghes_estatus_cache_add(ghes->generic, estatus);
The intent being, once this new error record is reported, it gets cached
so that it doesn't get reported for a while due to too many, same-type
error records getting reported in burst-like scenarios. I.e., new,
unreported error types can have a higher chance of getting reported.
Now, the loop in ghes_estatus_cache_add() is trying to pick out the
oldest element in there. Meaning, something which got reported already
but a long while ago, i.e., a LRU-type scheme.
And the cmpxchg() is there presumably to make sure when that selected
element slot_cache is removed, it really *is* that element that gets
removed and not one which replaced it in the meantime.
Now, ghes_estatus_cache_add() selects a slot, and either succeeds in
replacing its contents with a pointer to a newly cached item, or it just
gives up and frees the new item again, without attempting to select
another slot even if one might be available.
Since only inserting new items is being done here, the race can only
cause a failure if the selected slot was updated with another new item
concurrently, which means that it is arbitrary which of those two items
gets dropped.
And "dropped" here means, the item doesn't get added to the cache so
the next time it is seen, it'll get reported again and an insertion
attempt will be done again. Eventually, it'll get inserted and all those
times when the insertion fails, the item will get reported although the
cache is supposed to prevent that and "ratelimit" those repeated error
records. Not a big deal in any case.
This means the cmpxchg() and the special case are not necessary.
Therefore, just drop the existing item unconditionally.
Move the xchg_release() and call_rcu() out of rcu_read_lock/unlock
section since there is no actually dereferencing the pointer at all.
[ bp:
- Flesh out and summarize what was discussed on the thread now
that that cache contraption is understood;
- Touch up code style. ]
Co-developed-by: Jia He <justin.he@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221010023559.69655-7-justin.he@arm.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-10-24 23:43:41 +08:00
|
|
|
|
|
|
|
if (slot != -1) {
|
|
|
|
/*
|
|
|
|
* Use release semantics to ensure that ghes_estatus_cached()
|
|
|
|
* running on another CPU will see the updated cache fields if
|
|
|
|
* it can see the new value of the pointer.
|
|
|
|
*/
|
|
|
|
victim = xchg_release(&ghes_estatus_caches[slot],
|
|
|
|
RCU_INITIALIZER(new_cache));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* At this point, victim may point to a cached item different
|
|
|
|
* from the one based on which we selected the slot. Instead of
|
|
|
|
* going to the loop again to pick another slot, let's just
|
|
|
|
* drop the other item anyway: this may cause a false cache
|
|
|
|
* miss later on, but that won't cause any problems.
|
|
|
|
*/
|
|
|
|
if (victim)
|
|
|
|
call_rcu(&unrcu_pointer(victim)->rcu,
|
|
|
|
ghes_estatus_cache_rcu_free);
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
static void __ghes_panic(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 buf_paddr, enum fixed_addresses fixmap_idx)
|
2017-06-22 02:17:10 +08:00
|
|
|
{
|
2019-01-30 02:48:53 +08:00
|
|
|
__ghes_print_estatus(KERN_EMERG, ghes->generic, estatus);
|
2017-06-22 02:17:10 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);
|
2018-12-20 00:50:52 +08:00
|
|
|
|
2017-06-22 02:17:10 +08:00
|
|
|
/* reboot to log the error! */
|
|
|
|
if (!panic_timeout)
|
|
|
|
panic_timeout = ghes_panic_timeout;
|
|
|
|
panic("Fatal hardware error!");
|
|
|
|
}
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
static int ghes_proc(struct ghes *ghes)
|
|
|
|
{
|
2019-01-30 02:48:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus = ghes->estatus;
|
2019-01-30 02:48:42 +08:00
|
|
|
u64 buf_paddr;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
int rc;
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
rc = ghes_read_estatus(ghes, estatus, &buf_paddr, FIX_APEI_GHES_IRQ);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (rc)
|
|
|
|
goto out;
|
2017-06-22 02:17:10 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
if (ghes_severity(estatus->error_severity) >= GHES_SEV_PANIC)
|
|
|
|
__ghes_panic(ghes, estatus, buf_paddr, FIX_APEI_GHES_IRQ);
|
2017-06-22 02:17:10 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
if (!ghes_estatus_cached(estatus)) {
|
|
|
|
if (ghes_print_estatus(NULL, ghes->generic, estatus))
|
|
|
|
ghes_estatus_cache_add(ghes->generic, estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
}
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_do_proc(ghes, estatus);
|
2017-06-22 02:17:04 +08:00
|
|
|
|
2017-08-29 00:53:41 +08:00
|
|
|
out:
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, FIX_APEI_GHES_IRQ);
|
2017-08-29 00:53:41 +08:00
|
|
|
|
2016-10-19 00:07:19 +08:00
|
|
|
return rc;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
static void ghes_add_timer(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
struct acpi_hest_generic *g = ghes->generic;
|
|
|
|
unsigned long expire;
|
|
|
|
|
|
|
|
if (!g->notify.poll_interval) {
|
2019-10-18 11:18:25 +08:00
|
|
|
pr_warn(FW_WARN GHES_PFX "Poll interval is 0 for generic hardware error source: %d, disabled.\n",
|
|
|
|
g->header.source_id);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
expire = jiffies + msecs_to_jiffies(g->notify.poll_interval);
|
|
|
|
ghes->timer.expires = round_jiffies_relative(expire);
|
|
|
|
add_timer(&ghes->timer);
|
|
|
|
}
|
|
|
|
|
2017-10-13 07:19:27 +08:00
|
|
|
static void ghes_poll_func(struct timer_list *t)
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
{
|
2017-10-13 07:19:27 +08:00
|
|
|
struct ghes *ghes = from_timer(ghes, t, timer);
|
2019-01-30 02:48:51 +08:00
|
|
|
unsigned long flags;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
ghes_proc(ghes);
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
if (!(ghes->flags & GHES_EXITING))
|
|
|
|
ghes_add_timer(ghes);
|
|
|
|
}
|
|
|
|
|
|
|
|
static irqreturn_t ghes_irq_func(int irq, void *data)
|
|
|
|
{
|
|
|
|
struct ghes *ghes = data;
|
2019-01-30 02:48:51 +08:00
|
|
|
unsigned long flags;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
int rc;
|
|
|
|
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
rc = ghes_proc(ghes);
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
if (rc)
|
|
|
|
return IRQ_NONE;
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2017-05-19 17:39:11 +08:00
|
|
|
static int ghes_notify_hed(struct notifier_block *this, unsigned long event,
|
|
|
|
void *data)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
|
|
|
struct ghes *ghes;
|
2019-01-30 02:48:51 +08:00
|
|
|
unsigned long flags;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
int ret = NOTIFY_DONE;
|
|
|
|
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
rcu_read_lock();
|
2017-05-19 17:39:11 +08:00
|
|
|
list_for_each_entry_rcu(ghes, &ghes_hed, list) {
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (!ghes_proc(ghes))
|
|
|
|
ret = NOTIFY_OK;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-05-19 17:39:11 +08:00
|
|
|
static struct notifier_block ghes_notifier_hed = {
|
|
|
|
.notifier_call = ghes_notify_hed,
|
2014-07-22 17:20:12 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2019-01-30 02:48:47 +08:00
|
|
|
* Handlers for CPER records may not be NMI safe. For example,
|
|
|
|
* memory_failure_queue() takes spinlocks and calls schedule_work_on().
|
|
|
|
* In any NMI-like handler, memory from ghes_estatus_pool is used to save
|
|
|
|
* estatus, and added to the ghes_estatus_llist. irq_work_queue() causes
|
|
|
|
* ghes_proc_in_irq() to run in IRQ context where each estatus in
|
|
|
|
* ghes_estatus_llist is processed.
|
|
|
|
*
|
|
|
|
* Memory from the ghes_estatus_pool is also used with the ghes_estatus_cache
|
|
|
|
* to suppress frequent messages.
|
2014-07-22 17:20:12 +08:00
|
|
|
*/
|
|
|
|
static struct llist_head ghes_estatus_llist;
|
|
|
|
static struct irq_work ghes_proc_irq_work;
|
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
static void ghes_proc_in_irq(struct irq_work *irq_work)
|
|
|
|
{
|
2011-12-08 11:25:45 +08:00
|
|
|
struct llist_node *llnode, *next;
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
struct ghes_estatus_node *estatus_node;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
struct acpi_hest_generic *generic;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus;
|
2020-05-02 00:45:42 +08:00
|
|
|
bool task_work_pending;
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
u32 len, node_len;
|
2020-05-02 00:45:42 +08:00
|
|
|
int ret;
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
|
2011-12-08 11:25:45 +08:00
|
|
|
llnode = llist_del_all(&ghes_estatus_llist);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
/*
|
|
|
|
* Because the time order of estatus in list is reversed,
|
|
|
|
* revert it back to proper order.
|
|
|
|
*/
|
2014-07-28 14:50:59 +08:00
|
|
|
llnode = llist_reverse_order(llnode);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
while (llnode) {
|
|
|
|
next = llnode->next;
|
|
|
|
estatus_node = llist_entry(llnode, struct ghes_estatus_node,
|
|
|
|
llnode);
|
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(estatus);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(len);
|
2020-05-02 00:45:42 +08:00
|
|
|
task_work_pending = ghes_do_proc(estatus_node->ghes, estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
if (!ghes_estatus_cached(estatus)) {
|
|
|
|
generic = estatus_node->generic;
|
|
|
|
if (ghes_print_estatus(NULL, generic, estatus))
|
|
|
|
ghes_estatus_cache_add(generic, estatus);
|
|
|
|
}
|
2020-05-02 00:45:42 +08:00
|
|
|
|
ACPI: APEI: do not add task_work to kernel thread to avoid memory leak
If an error is detected as a result of user-space process accessing a
corrupt memory location, the CPU may take an abort. Then the platform
firmware reports kernel via NMI like notifications, e.g. NOTIFY_SEA,
NOTIFY_SOFTWARE_DELEGATED, etc.
For NMI like notifications, commit 7f17b4a121d0 ("ACPI: APEI: Kick the
memory_failure() queue for synchronous errors") keep track of whether
memory_failure() work was queued, and make task_work pending to flush out
the queue so that the work is processed before return to user-space.
The code use init_mm to check whether the error occurs in user space:
if (current->mm != &init_mm)
The condition is always true, becase _nobody_ ever has "init_mm" as a real
VM any more.
In addition to abort, errors can also be signaled as asynchronous
exceptions, such as interrupt and SError. In such case, the interrupted
current process could be any kind of thread. When a kernel thread is
interrupted, the work ghes_kick_task_work deferred to task_work will never
be processed because entry_handler returns to call ret_to_kernel() instead
of ret_to_user(). Consequently, the estatus_node alloced from
ghes_estatus_pool in ghes_in_nmi_queue_one_entry() will not be freed.
After around 200 allocations in our platform, the ghes_estatus_pool will
run of memory and ghes_in_nmi_queue_one_entry() returns ENOMEM. As a
result, the event failed to be processed.
sdei: event 805 on CPU 113 failed with error: -2
Finally, a lot of unhandled events may cause platform firmware to exceed
some threshold and reboot.
The condition should generally just do
if (current->mm)
as described in active_mm.rst documentation.
Then if an asynchronous error is detected when a kernel thread is running,
(e.g. when detected by a background scrubber), do not add task_work to it
as the original patch intends to do.
Fixes: 7f17b4a121d0 ("ACPI: APEI: Kick the memory_failure() queue for synchronous errors")
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2022-09-24 15:49:53 +08:00
|
|
|
if (task_work_pending && current->mm) {
|
2020-05-02 00:45:42 +08:00
|
|
|
estatus_node->task_work.func = ghes_kick_task_work;
|
|
|
|
estatus_node->task_work_cpu = smp_processor_id();
|
|
|
|
ret = task_work_add(current, &estatus_node->task_work,
|
task_work: cleanup notification modes
A previous commit changed the notification mode from true/false to an
int, allowing notify-no, notify-yes, or signal-notify. This was
backwards compatible in the sense that any existing true/false user
would translate to either 0 (on notification sent) or 1, the latter
which mapped to TWA_RESUME. TWA_SIGNAL was assigned a value of 2.
Clean this up properly, and define a proper enum for the notification
mode. Now we have:
- TWA_NONE. This is 0, same as before the original change, meaning no
notification requested.
- TWA_RESUME. This is 1, same as before the original change, meaning
that we use TIF_NOTIFY_RESUME.
- TWA_SIGNAL. This uses TIF_SIGPENDING/JOBCTL_TASK_WORK for the
notification.
Clean up all the callers, switching their 0/1/false/true to using the
appropriate TWA_* mode for notifications.
Fixes: e91b48162332 ("task_work: teach task_work_add() to do signal_wake_up()")
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
2020-10-16 23:02:26 +08:00
|
|
|
TWA_RESUME);
|
2020-05-02 00:45:42 +08:00
|
|
|
if (ret)
|
|
|
|
estatus_node->task_work.func = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!estatus_node->task_work.func)
|
|
|
|
gen_pool_free(ghes_estatus_pool,
|
|
|
|
(unsigned long)estatus_node, node_len);
|
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
llnode = next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-08 11:25:45 +08:00
|
|
|
static void ghes_print_queued_estatus(void)
|
|
|
|
{
|
|
|
|
struct llist_node *llnode;
|
|
|
|
struct ghes_estatus_node *estatus_node;
|
|
|
|
struct acpi_hest_generic *generic;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus;
|
2011-12-08 11:25:45 +08:00
|
|
|
|
|
|
|
llnode = llist_del_all(&ghes_estatus_llist);
|
|
|
|
/*
|
|
|
|
* Because the time order of estatus in list is reversed,
|
|
|
|
* revert it back to proper order.
|
|
|
|
*/
|
2014-07-28 14:50:59 +08:00
|
|
|
llnode = llist_reverse_order(llnode);
|
2011-12-08 11:25:45 +08:00
|
|
|
while (llnode) {
|
|
|
|
estatus_node = llist_entry(llnode, struct ghes_estatus_node,
|
|
|
|
llnode);
|
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
|
|
|
generic = estatus_node->generic;
|
|
|
|
ghes_print_estatus(NULL, generic, estatus);
|
|
|
|
llnode = llnode->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
2015-03-18 16:41:35 +08:00
|
|
|
{
|
2019-01-30 02:48:56 +08:00
|
|
|
struct acpi_hest_generic_status *estatus, tmp_header;
|
2015-03-18 16:41:35 +08:00
|
|
|
struct ghes_estatus_node *estatus_node;
|
2019-01-30 02:48:56 +08:00
|
|
|
u32 len, node_len;
|
|
|
|
u64 buf_paddr;
|
|
|
|
int sev, rc;
|
2015-03-18 16:41:35 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG))
|
2019-01-30 02:48:56 +08:00
|
|
|
return -EOPNOTSUPP;
|
2015-03-18 16:41:35 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
rc = __ghes_peek_estatus(ghes, &tmp_header, &buf_paddr, fixmap_idx);
|
|
|
|
if (rc) {
|
|
|
|
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
|
|
|
|
return rc;
|
|
|
|
}
|
2019-01-30 02:48:53 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
rc = __ghes_check_estatus(ghes, &tmp_header);
|
|
|
|
if (rc) {
|
|
|
|
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
|
|
|
|
return rc;
|
|
|
|
}
|
2015-03-18 16:41:35 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
len = cper_estatus_len(&tmp_header);
|
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(len);
|
2015-03-18 16:41:35 +08:00
|
|
|
estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
|
|
|
|
if (!estatus_node)
|
2019-01-30 02:48:56 +08:00
|
|
|
return -ENOMEM;
|
2015-03-18 16:41:35 +08:00
|
|
|
|
|
|
|
estatus_node->ghes = ghes;
|
|
|
|
estatus_node->generic = ghes->generic;
|
2020-05-02 00:45:42 +08:00
|
|
|
estatus_node->task_work.func = NULL;
|
2015-03-18 16:41:35 +08:00
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
if (__ghes_read_estatus(estatus, buf_paddr, fixmap_idx, len)) {
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);
|
2019-01-30 02:48:56 +08:00
|
|
|
rc = -ENOENT;
|
|
|
|
goto no_work;
|
2019-01-30 02:48:45 +08:00
|
|
|
}
|
2015-03-27 17:05:00 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
sev = ghes_severity(estatus->error_severity);
|
2019-01-30 02:48:45 +08:00
|
|
|
if (sev >= GHES_SEV_PANIC) {
|
|
|
|
ghes_print_queued_estatus();
|
2019-01-30 02:48:53 +08:00
|
|
|
__ghes_panic(ghes, estatus, buf_paddr, fixmap_idx);
|
2019-01-30 02:48:45 +08:00
|
|
|
}
|
2015-03-18 16:55:21 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
|
2015-03-18 16:55:21 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
/* This error has been reported before, don't process it again. */
|
|
|
|
if (ghes_estatus_cached(estatus))
|
|
|
|
goto no_work;
|
|
|
|
|
|
|
|
llist_add(&estatus_node->llnode, &ghes_estatus_llist);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
no_work:
|
|
|
|
gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
|
|
|
|
node_len);
|
|
|
|
|
|
|
|
return rc;
|
2019-01-30 02:48:45 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
static int ghes_in_nmi_spool_from_list(struct list_head *rcu_list,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
2019-01-30 02:48:45 +08:00
|
|
|
{
|
|
|
|
int ret = -ENOENT;
|
|
|
|
struct ghes *ghes;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(ghes, rcu_list, list) {
|
2019-01-30 02:48:52 +08:00
|
|
|
if (!ghes_in_nmi_queue_one_entry(ghes, fixmap_idx))
|
2019-01-30 02:48:45 +08:00
|
|
|
ret = 0;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
2019-01-30 02:48:45 +08:00
|
|
|
rcu_read_unlock();
|
2015-03-18 16:41:35 +08:00
|
|
|
|
2019-01-30 02:48:45 +08:00
|
|
|
if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && !ret)
|
2016-11-30 21:19:39 +08:00
|
|
|
irq_work_queue(&ghes_proc_irq_work);
|
2019-01-30 02:48:45 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2019-01-30 02:48:47 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_APEI_SEA
|
|
|
|
static LIST_HEAD(ghes_sea);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return 0 only if one of the SEA error sources successfully reported an error
|
|
|
|
* record sent from the firmware.
|
|
|
|
*/
|
|
|
|
int ghes_notify_sea(void)
|
|
|
|
{
|
2019-01-30 02:48:51 +08:00
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_notify_lock_sea);
|
|
|
|
int rv;
|
|
|
|
|
|
|
|
raw_spin_lock(&ghes_notify_lock_sea);
|
2019-01-30 02:48:57 +08:00
|
|
|
rv = ghes_in_nmi_spool_from_list(&ghes_sea, FIX_APEI_GHES_SEA);
|
2019-01-30 02:48:51 +08:00
|
|
|
raw_spin_unlock(&ghes_notify_lock_sea);
|
|
|
|
|
|
|
|
return rv;
|
2019-01-30 02:48:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_sea_add(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_add_rcu(&ghes->list, &ghes_sea);
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_sea_remove(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_del_rcu(&ghes->list);
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
|
|
|
synchronize_rcu();
|
|
|
|
}
|
|
|
|
#else /* CONFIG_ACPI_APEI_SEA */
|
|
|
|
static inline void ghes_sea_add(struct ghes *ghes) { }
|
|
|
|
static inline void ghes_sea_remove(struct ghes *ghes) { }
|
|
|
|
#endif /* CONFIG_ACPI_APEI_SEA */
|
|
|
|
|
|
|
|
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
|
|
|
|
/*
|
|
|
|
* NMI may be triggered on any CPU, so ghes_in_nmi is used for
|
|
|
|
* having only one concurrent reader.
|
|
|
|
*/
|
|
|
|
static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
|
|
|
|
|
|
|
|
static LIST_HEAD(ghes_nmi);
|
2019-01-30 02:48:45 +08:00
|
|
|
|
|
|
|
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
|
|
|
|
{
|
2019-01-30 02:48:51 +08:00
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_notify_lock_nmi);
|
2019-01-30 02:48:45 +08:00
|
|
|
int ret = NMI_DONE;
|
|
|
|
|
|
|
|
if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
|
|
|
|
return ret;
|
|
|
|
|
2019-01-30 02:48:51 +08:00
|
|
|
raw_spin_lock(&ghes_notify_lock_nmi);
|
2019-01-30 02:48:52 +08:00
|
|
|
if (!ghes_in_nmi_spool_from_list(&ghes_nmi, FIX_APEI_GHES_NMI))
|
2019-01-30 02:48:45 +08:00
|
|
|
ret = NMI_HANDLED;
|
2019-01-30 02:48:51 +08:00
|
|
|
raw_spin_unlock(&ghes_notify_lock_nmi);
|
2019-01-30 02:48:45 +08:00
|
|
|
|
2015-03-27 17:05:00 +08:00
|
|
|
atomic_dec(&ghes_in_nmi);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-07-22 17:20:12 +08:00
|
|
|
static void ghes_nmi_add(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
if (list_empty(&ghes_nmi))
|
|
|
|
register_nmi_handler(NMI_LOCAL, ghes_notify_nmi, 0, "ghes");
|
|
|
|
list_add_rcu(&ghes->list, &ghes_nmi);
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_nmi_remove(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_del_rcu(&ghes->list);
|
|
|
|
if (list_empty(&ghes_nmi))
|
|
|
|
unregister_nmi_handler(NMI_LOCAL, "ghes");
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
|
|
|
/*
|
|
|
|
* To synchronize with NMI handler, ghes can only be
|
|
|
|
* freed after NMI handler finishes.
|
|
|
|
*/
|
|
|
|
synchronize_rcu();
|
|
|
|
}
|
2019-01-30 02:48:48 +08:00
|
|
|
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
|
|
|
|
static inline void ghes_nmi_add(struct ghes *ghes) { }
|
|
|
|
static inline void ghes_nmi_remove(struct ghes *ghes) { }
|
|
|
|
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
|
2014-07-22 17:20:12 +08:00
|
|
|
|
|
|
|
static void ghes_nmi_init_cxt(void)
|
|
|
|
{
|
|
|
|
init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:49:02 +08:00
|
|
|
static int __ghes_sdei_callback(struct ghes *ghes,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
|
|
|
{
|
|
|
|
if (!ghes_in_nmi_queue_one_entry(ghes, fixmap_idx)) {
|
|
|
|
irq_work_queue(&ghes_proc_irq_work);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ghes_sdei_normal_callback(u32 event_num, struct pt_regs *regs,
|
|
|
|
void *arg)
|
|
|
|
{
|
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_notify_lock_sdei_normal);
|
|
|
|
struct ghes *ghes = arg;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
raw_spin_lock(&ghes_notify_lock_sdei_normal);
|
|
|
|
err = __ghes_sdei_callback(ghes, FIX_APEI_GHES_SDEI_NORMAL);
|
|
|
|
raw_spin_unlock(&ghes_notify_lock_sdei_normal);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ghes_sdei_critical_callback(u32 event_num, struct pt_regs *regs,
|
|
|
|
void *arg)
|
|
|
|
{
|
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_notify_lock_sdei_critical);
|
|
|
|
struct ghes *ghes = arg;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
raw_spin_lock(&ghes_notify_lock_sdei_critical);
|
|
|
|
err = __ghes_sdei_callback(ghes, FIX_APEI_GHES_SDEI_CRITICAL);
|
|
|
|
raw_spin_unlock(&ghes_notify_lock_sdei_critical);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int apei_sdei_register_ghes(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
if (!IS_ENABLED(CONFIG_ARM_SDE_INTERFACE))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
return sdei_register_ghes(ghes, ghes_sdei_normal_callback,
|
|
|
|
ghes_sdei_critical_callback);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int apei_sdei_unregister_ghes(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
if (!IS_ENABLED(CONFIG_ARM_SDE_INTERFACE))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
return sdei_unregister_ghes(ghes);
|
|
|
|
}
|
|
|
|
|
2012-11-20 02:22:46 +08:00
|
|
|
static int ghes_probe(struct platform_device *ghes_dev)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
|
|
|
struct acpi_hest_generic *generic;
|
|
|
|
struct ghes *ghes = NULL;
|
2019-01-30 02:48:51 +08:00
|
|
|
unsigned long flags;
|
2014-07-22 17:20:12 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
int rc = -EINVAL;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2010-09-29 19:53:53 +08:00
|
|
|
generic = *(struct acpi_hest_generic **)ghes_dev->dev.platform_data;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (!generic->enabled)
|
2010-08-02 15:48:24 +08:00
|
|
|
return -ENODEV;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
switch (generic->notify.type) {
|
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 17:39:11 +08:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2014-07-22 17:20:12 +08:00
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
2017-06-22 02:17:09 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SEA:
|
|
|
|
if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
|
|
|
|
pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEA is not supported\n",
|
|
|
|
generic->header.source_id);
|
|
|
|
rc = -ENOTSUPP;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 17:20:12 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
|
|
|
|
pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
|
|
|
|
generic->header.source_id);
|
|
|
|
goto err;
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
2019-01-30 02:49:02 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
|
|
|
|
if (!IS_ENABLED(CONFIG_ARM_SDE_INTERFACE)) {
|
|
|
|
pr_warn(GHES_PFX "Generic hardware error source: %d notified via SDE Interface is not supported!\n",
|
|
|
|
generic->header.source_id);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_LOCAL:
|
2019-10-18 11:18:25 +08:00
|
|
|
pr_warn(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
|
|
|
|
generic->header.source_id);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
goto err;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
default:
|
2019-10-18 11:18:25 +08:00
|
|
|
pr_warn(FW_WARN GHES_PFX "Unknown notification type: %u for generic hardware error source: %d\n",
|
|
|
|
generic->notify.type, generic->header.source_id);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
goto err;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
|
|
|
rc = -EIO;
|
|
|
|
if (generic->error_block_length <
|
2014-06-03 16:32:53 +08:00
|
|
|
sizeof(struct acpi_hest_generic_status)) {
|
2019-10-18 11:18:25 +08:00
|
|
|
pr_warn(FW_BUG GHES_PFX "Invalid error block length: %u for generic hardware error source: %d\n",
|
|
|
|
generic->error_block_length, generic->header.source_id);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
ghes = ghes_new(generic);
|
|
|
|
if (IS_ERR(ghes)) {
|
|
|
|
rc = PTR_ERR(ghes);
|
|
|
|
ghes = NULL;
|
|
|
|
goto err;
|
|
|
|
}
|
2013-02-15 17:10:39 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
switch (generic->notify.type) {
|
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
2020-01-09 01:17:38 +08:00
|
|
|
timer_setup(&ghes->timer, ghes_poll_func, 0);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
ghes_add_timer(ghes);
|
|
|
|
break;
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
/* External interrupt vector is GSI */
|
2013-06-03 10:08:39 +08:00
|
|
|
rc = acpi_gsi_to_irq(generic->notify.vector, &ghes->irq);
|
|
|
|
if (rc) {
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
pr_err(GHES_PFX "Failed to map GSI to IRQ for generic hardware error source: %d\n",
|
|
|
|
generic->header.source_id);
|
2018-04-23 20:16:46 +08:00
|
|
|
goto err;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
2017-07-22 02:24:37 +08:00
|
|
|
rc = request_irq(ghes->irq, ghes_irq_func, IRQF_SHARED,
|
|
|
|
"GHES IRQ", ghes);
|
2013-06-03 10:08:39 +08:00
|
|
|
if (rc) {
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
pr_err(GHES_PFX "Failed to register IRQ for generic hardware error source: %d\n",
|
|
|
|
generic->header.source_id);
|
2018-04-23 20:16:46 +08:00
|
|
|
goto err;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 17:39:11 +08:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_lock(&ghes_list_mutex);
|
2017-05-19 17:39:11 +08:00
|
|
|
if (list_empty(&ghes_hed))
|
|
|
|
register_acpi_hed_notifier(&ghes_notifier_hed);
|
|
|
|
list_add_rcu(&ghes->list, &ghes_hed);
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_unlock(&ghes_list_mutex);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
2017-06-22 02:17:09 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SEA:
|
|
|
|
ghes_sea_add(ghes);
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 17:20:12 +08:00
|
|
|
ghes_nmi_add(ghes);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
2019-01-30 02:49:02 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
|
|
|
|
rc = apei_sdei_register_ghes(ghes);
|
|
|
|
if (rc)
|
|
|
|
goto err;
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
default:
|
|
|
|
BUG();
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
2018-04-23 20:16:46 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
platform_set_drvdata(ghes_dev, ghes);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2022-10-10 10:35:55 +08:00
|
|
|
ghes->dev = &ghes_dev->dev;
|
|
|
|
|
|
|
|
mutex_lock(&ghes_devs_mutex);
|
|
|
|
list_add_tail(&ghes->elist, &ghes_devs);
|
|
|
|
mutex_unlock(&ghes_devs_mutex);
|
2018-04-23 20:16:46 +08:00
|
|
|
|
2017-06-22 02:17:15 +08:00
|
|
|
/* Handle any pending errors right away */
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
2017-06-22 02:17:15 +08:00
|
|
|
ghes_proc(ghes);
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
2017-06-22 02:17:15 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
return 0;
|
2018-04-23 20:16:46 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
err:
|
2010-08-02 15:48:24 +08:00
|
|
|
if (ghes) {
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
ghes_fini(ghes);
|
2010-08-02 15:48:24 +08:00
|
|
|
kfree(ghes);
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2012-11-22 06:13:09 +08:00
|
|
|
static int ghes_remove(struct platform_device *ghes_dev)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
2019-01-30 02:49:02 +08:00
|
|
|
int rc;
|
2010-08-02 15:48:24 +08:00
|
|
|
struct ghes *ghes;
|
|
|
|
struct acpi_hest_generic *generic;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
ghes = platform_get_drvdata(ghes_dev);
|
|
|
|
generic = ghes->generic;
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
ghes->flags |= GHES_EXITING;
|
2010-08-02 15:48:24 +08:00
|
|
|
switch (generic->notify.type) {
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
2022-12-21 02:45:19 +08:00
|
|
|
timer_shutdown_sync(&ghes->timer);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
free_irq(ghes->irq, ghes);
|
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 17:39:11 +08:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_del_rcu(&ghes->list);
|
2017-05-19 17:39:11 +08:00
|
|
|
if (list_empty(&ghes_hed))
|
|
|
|
unregister_acpi_hed_notifier(&ghes_notifier_hed);
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_unlock(&ghes_list_mutex);
|
2017-03-16 22:30:39 +08:00
|
|
|
synchronize_rcu();
|
2010-08-02 15:48:24 +08:00
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
2017-06-22 02:17:09 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SEA:
|
|
|
|
ghes_sea_remove(ghes);
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 17:20:12 +08:00
|
|
|
ghes_nmi_remove(ghes);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
2019-01-30 02:49:02 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
|
|
|
|
rc = apei_sdei_unregister_ghes(ghes);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
break;
|
2010-08-02 15:48:24 +08:00
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
break;
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
ghes_fini(ghes);
|
2013-02-15 17:10:39 +08:00
|
|
|
|
2022-10-10 10:35:55 +08:00
|
|
|
mutex_lock(&ghes_devs_mutex);
|
|
|
|
list_del(&ghes->elist);
|
|
|
|
mutex_unlock(&ghes_devs_mutex);
|
2013-02-15 17:10:39 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
kfree(ghes);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
return 0;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
static struct platform_driver ghes_platform_driver = {
|
|
|
|
.driver = {
|
|
|
|
.name = "GHES",
|
|
|
|
},
|
|
|
|
.probe = ghes_probe,
|
|
|
|
.remove = ghes_remove,
|
|
|
|
};
|
|
|
|
|
2022-02-27 20:25:46 +08:00
|
|
|
void __init acpi_ghes_init(void)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
int rc;
|
|
|
|
|
2022-02-27 20:25:45 +08:00
|
|
|
sdei_init();
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (acpi_disabled)
|
2022-02-27 20:25:45 +08:00
|
|
|
return;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2017-08-29 21:20:20 +08:00
|
|
|
switch (hest_disable) {
|
|
|
|
case HEST_NOT_FOUND:
|
2022-02-27 20:25:45 +08:00
|
|
|
return;
|
2017-08-29 21:20:20 +08:00
|
|
|
case HEST_DISABLED:
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
pr_info(GHES_PFX "HEST is not enabled!\n");
|
2022-02-27 20:25:45 +08:00
|
|
|
return;
|
2017-08-29 21:20:20 +08:00
|
|
|
default:
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2011-07-13 13:14:19 +08:00
|
|
|
if (ghes_disable) {
|
|
|
|
pr_info(GHES_PFX "GHES is not enabled!\n");
|
2022-02-27 20:25:45 +08:00
|
|
|
return;
|
2011-07-13 13:14:19 +08:00
|
|
|
}
|
|
|
|
|
2014-07-22 17:20:12 +08:00
|
|
|
ghes_nmi_init_cxt();
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
|
|
|
|
rc = platform_driver_register(&ghes_platform_driver);
|
|
|
|
if (rc)
|
2022-02-27 20:25:45 +08:00
|
|
|
return;
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
|
2011-07-13 13:14:21 +08:00
|
|
|
rc = apei_osc_setup();
|
|
|
|
if (rc == 0 && osc_sb_apei_support_acked)
|
|
|
|
pr_info(GHES_PFX "APEI firmware first mode is enabled by APEI bit and WHEA _OSC.\n");
|
|
|
|
else if (rc == 0 && !osc_sb_apei_support_acked)
|
|
|
|
pr_info(GHES_PFX "APEI firmware first mode is enabled by WHEA _OSC.\n");
|
|
|
|
else if (rc && osc_sb_apei_support_acked)
|
|
|
|
pr_info(GHES_PFX "APEI firmware first mode is enabled by APEI bit.\n");
|
|
|
|
else
|
|
|
|
pr_info(GHES_PFX "Failed to enable APEI firmware first mode.\n");
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
2022-10-10 10:35:54 +08:00
|
|
|
|
2022-10-10 10:35:55 +08:00
|
|
|
/*
|
|
|
|
* Known x86 systems that prefer GHES error reporting:
|
|
|
|
*/
|
|
|
|
static struct acpi_platform_list plat_list[] = {
|
|
|
|
{"HPE ", "Server ", 0, ACPI_SIG_FADT, all_versions},
|
|
|
|
{ } /* End */
|
|
|
|
};
|
|
|
|
|
|
|
|
struct list_head *ghes_get_devices(void)
|
|
|
|
{
|
|
|
|
int idx = -1;
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_X86)) {
|
|
|
|
idx = acpi_match_platform_list(plat_list);
|
|
|
|
if (idx < 0) {
|
|
|
|
if (!ghes_edac_force_enable)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
pr_warn_once("Force-loading ghes_edac on an unsupported platform. You're on your own!\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return &ghes_devs;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ghes_get_devices);
|
|
|
|
|
2022-10-10 10:35:54 +08:00
|
|
|
void ghes_register_report_chain(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
atomic_notifier_chain_register(&ghes_report_chain, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ghes_register_report_chain);
|
|
|
|
|
|
|
|
void ghes_unregister_report_chain(struct notifier_block *nb)
|
|
|
|
{
|
|
|
|
atomic_notifier_chain_unregister(&ghes_report_chain, nb);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(ghes_unregister_report_chain);
|