2019-05-27 06:55:21 +00: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 06:35:20 +00: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 05:14:25 +00: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 06:35:20 +00:00
|
|
|
* Author: Huang Ying <ying.huang@intel.com>
|
|
|
|
*/
|
|
|
|
|
2019-01-29 18:49:02 +00: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 06:35:20 +00:00
|
|
|
#include <linux/kernel.h>
|
2016-02-15 05:27:50 +00: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 06:35:20 +00: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 06:44:55 +00: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 06:35:20 +00:00
|
|
|
#include <linux/cper.h>
|
2010-08-02 07:48:24 +00:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/mutex.h>
|
2010-12-07 02:22:31 +00: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 06:44:55 +00: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 05:14:25 +00:00
|
|
|
#include <linux/irq_work.h>
|
|
|
|
#include <linux/llist.h>
|
|
|
|
#include <linux/genalloc.h>
|
2011-12-08 03:25:41 +00:00
|
|
|
#include <linux/pci.h>
|
2019-01-29 18:48:52 +00:00
|
|
|
#include <linux/pfn.h>
|
2011-12-08 03:25:41 +00:00
|
|
|
#include <linux/aer.h>
|
2014-07-22 09:20:12 +00:00
|
|
|
#include <linux/nmi.h>
|
2017-02-01 15:36:40 +00:00
|
|
|
#include <linux/sched/clock.h>
|
2017-06-21 18:17:12 +00:00
|
|
|
#include <linux/uuid.h>
|
|
|
|
#include <linux/ras.h>
|
2020-05-01 16:45:42 +00:00
|
|
|
#include <linux/task_work.h>
|
2013-02-15 08:41:22 +00:00
|
|
|
|
2017-06-21 18:17:04 +00:00
|
|
|
#include <acpi/actbl1.h>
|
2013-02-15 08:41:22 +00:00
|
|
|
#include <acpi/ghes.h>
|
2014-07-22 09:20:11 +00:00
|
|
|
#include <acpi/apei.h>
|
2017-11-06 18:44:24 +00: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 06:44:55 +00:00
|
|
|
#include <asm/tlbflush.h>
|
2017-06-21 18:17:12 +00: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 06:35:20 +00: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 05:14:25 +00: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 05:14:26 +00: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-02 22:00:21 +00: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 05:14:26 +00: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 08:32:53 +00: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 05:14:26 +00: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 05:14:25 +00:00
|
|
|
#define GHES_ESTATUS_NODE_LEN(estatus_len) \
|
|
|
|
(sizeof(struct ghes_estatus_node) + (estatus_len))
|
2013-10-18 21:28:59 +00:00
|
|
|
#define GHES_ESTATUS_FROM_NODE(estatus_node) \
|
2014-06-03 08:32:53 +00: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 05:14:25 +00: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 06:35:20 +00:00
|
|
|
|
2020-09-03 12:34:55 +00: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-29 18:49:02 +00: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
|
|
|
|
|
2017-06-21 18:17:04 +00:00
|
|
|
static inline bool is_hest_type_generic_v2(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
return ghes->generic->header.type == ACPI_HEST_TYPE_GENERIC_ERROR_V2;
|
|
|
|
}
|
|
|
|
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
/*
|
|
|
|
* A platform may describe one error source for the handling of synchronous
|
|
|
|
* errors (e.g. MCE or SEA), or for handling asynchronous errors (e.g. SCI
|
|
|
|
* or External Interrupt). On x86, the HEST notifications are always
|
|
|
|
* asynchronous, so only SEA on ARM is delivered as a synchronous
|
|
|
|
* notification.
|
|
|
|
*/
|
|
|
|
static inline bool is_hest_sync_notify(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
u8 notify_type = ghes->generic->notify.type;
|
|
|
|
|
|
|
|
return notify_type == ACPI_HEST_NOTIFY_SEA;
|
|
|
|
}
|
|
|
|
|
2016-02-15 05:27:50 +00: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-12 23:02:20 +00:00
|
|
|
bool ghes_disable;
|
2011-07-13 05:14:19 +00:00
|
|
|
module_param_named(disable, ghes_disable, 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 06:35:20 +00:00
|
|
|
/*
|
2017-05-19 09:39:11 +00: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 06:35:20 +00: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 06:44:55 +00: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 06:35:20 +00:00
|
|
|
*/
|
2017-05-19 09:39:11 +00:00
|
|
|
static LIST_HEAD(ghes_hed);
|
2010-08-02 07:48:24 +00: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 06:35:20 +00: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 06:44:55 +00: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-06 18:44:24 +00:00
|
|
|
* the fixmap is used instead.
|
2017-11-06 18:44:25 +00:00
|
|
|
*
|
2019-01-29 18:48:51 +00:00
|
|
|
* This spinlock is used to prevent the fixmap entry from being used
|
2017-11-06 18:44:24 +00: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 06:44:55 +00:00
|
|
|
*/
|
2019-01-29 18:48:51 +00: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 06:44:55 +00:00
|
|
|
|
2020-09-03 12:34:55 +00: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 05:14:25 +00:00
|
|
|
static struct gen_pool *ghes_estatus_pool;
|
|
|
|
static unsigned long ghes_estatus_pool_size_request;
|
|
|
|
|
2014-09-29 11:33:17 +00:00
|
|
|
static struct ghes_estatus_cache *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 05:14:26 +00:00
|
|
|
static atomic_t ghes_estatus_cache_alloced;
|
|
|
|
|
2017-06-21 18:17:10 +00:00
|
|
|
static int ghes_panic_timeout __read_mostly = 30;
|
|
|
|
|
2019-01-29 18:48:52 +00: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 06:44:55 +00:00
|
|
|
{
|
2017-06-21 18:17:09 +00: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 06:44:55 +00:00
|
|
|
|
2019-01-29 18:48:52 +00:00
|
|
|
paddr = PFN_PHYS(pfn);
|
2017-06-21 18:17:09 +00:00
|
|
|
prot = arch_apei_get_mem_attribute(paddr);
|
2019-01-29 18:48:52 +00: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 06:44:55 +00:00
|
|
|
|
2019-01-29 18:48:52 +00: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 06:44:55 +00:00
|
|
|
}
|
|
|
|
|
2019-01-29 18:48:52 +00: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 06:44:55 +00:00
|
|
|
{
|
2019-01-29 18:48:52 +00: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 13:11:42 +00:00
|
|
|
|
2019-01-29 18:48:52 +00: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 06:44:55 +00:00
|
|
|
}
|
|
|
|
|
2022-10-05 16:32:53 +00: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 05:14:25 +00:00
|
|
|
{
|
2019-01-29 18:48:41 +00:00
|
|
|
unsigned long addr, len;
|
2019-07-15 06:58:44 +00:00
|
|
|
int rc;
|
2019-01-29 18:48:41 +00: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 05:14:25 +00:00
|
|
|
ghes_estatus_pool = gen_pool_create(GHES_ESTATUS_POOL_MIN_ALLOC_ORDER, -1);
|
|
|
|
if (!ghes_estatus_pool)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-01-29 18:48:41 +00: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 05:14:25 +00:00
|
|
|
|
2019-01-29 18:48:41 +00:00
|
|
|
ghes_estatus_pool_size_request = PAGE_ALIGN(len);
|
2019-01-29 18:48:39 +00:00
|
|
|
addr = (unsigned long)vmalloc(PAGE_ALIGN(len));
|
|
|
|
if (!addr)
|
2019-07-15 06:58:44 +00:00
|
|
|
goto err_pool_alloc;
|
2019-01-29 18:48:39 +00:00
|
|
|
|
2019-07-15 06:58:44 +00: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 05:14:25 +00:00
|
|
|
}
|
|
|
|
|
2017-06-21 18:17:04 +00: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-29 18:48:46 +00: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 06:35:20 +00: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-21 18:17:04 +00: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 06:35:20 +00:00
|
|
|
ghes->generic = generic;
|
2017-06-21 18:17:04 +00:00
|
|
|
if (is_hest_type_generic_v2(ghes)) {
|
|
|
|
rc = map_gen_v2(ghes);
|
|
|
|
if (rc)
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
2012-06-12 03:20:19 +00: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 06:35:20 +00:00
|
|
|
if (rc)
|
2017-06-21 18:17:04 +00: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 06:35:20 +00:00
|
|
|
error_block_length = generic->error_block_length;
|
|
|
|
if (error_block_length > GHES_ESTATUS_MAX_SIZE) {
|
2019-10-18 03:18:25 +00: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 06:35:20 +00:00
|
|
|
error_block_length = GHES_ESTATUS_MAX_SIZE;
|
|
|
|
}
|
|
|
|
ghes->estatus = kmalloc(error_block_length, GFP_KERNEL);
|
|
|
|
if (!ghes->estatus) {
|
|
|
|
rc = -ENOMEM;
|
2017-06-21 18:17:04 +00: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 06:35:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return ghes;
|
|
|
|
|
2017-06-21 18:17:04 +00:00
|
|
|
err_unmap_status_addr:
|
2012-06-12 03:20:19 +00:00
|
|
|
apei_unmap_generic_address(&generic->error_status_address);
|
2017-06-21 18:17:04 +00: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 06:35:20 +00:00
|
|
|
err_free:
|
|
|
|
kfree(ghes);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_fini(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
kfree(ghes->estatus);
|
2012-06-12 03:20:19 +00:00
|
|
|
apei_unmap_generic_address(&ghes->generic->error_status_address);
|
2017-06-21 18:17:04 +00: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 06:35:20 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int ghes_severity(int severity)
|
|
|
|
{
|
|
|
|
switch (severity) {
|
2010-08-02 07:48:23 +00: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 06:35:20 +00:00
|
|
|
default:
|
2011-03-31 01:57:33 +00:00
|
|
|
/* Unknown, go panic */
|
2010-08-02 07:48:23 +00: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 06:35:20 +00: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 06:44:55 +00:00
|
|
|
static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
|
2019-01-29 18:48:52 +00: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 06:35:20 +00: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 06:44:55 +00:00
|
|
|
void __iomem *vaddr;
|
|
|
|
u64 offset;
|
|
|
|
u32 trunk;
|
|
|
|
|
|
|
|
while (len > 0) {
|
|
|
|
offset = paddr - (paddr & PAGE_MASK);
|
2019-01-29 18:48:52 +00: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 06:44:55 +00: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-29 18:48:52 +00: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 06:44:55 +00: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 06:35:20 +00:00
|
|
|
}
|
|
|
|
|
2019-01-29 18:48:54 +00: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-29 18:48:55 +00: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 06:35:20 +00:00
|
|
|
{
|
|
|
|
struct acpi_hest_generic *g = ghes->generic;
|
|
|
|
int rc;
|
|
|
|
|
2019-01-29 18:48:42 +00: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 06:35:20 +00:00
|
|
|
if (rc) {
|
2019-01-29 18:48:42 +00:00
|
|
|
*buf_paddr = 0;
|
2019-01-29 18:48:38 +00: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 06:35:20 +00:00
|
|
|
"Failed to read error status block address for hardware error source: %d.\n",
|
|
|
|
g->header.source_id);
|
|
|
|
return -EIO;
|
|
|
|
}
|
2019-01-29 18:48:42 +00: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 06:35:20 +00:00
|
|
|
return -ENOENT;
|
|
|
|
|
2019-01-29 18:48:53 +00:00
|
|
|
ghes_copy_tofrom_phys(estatus, *buf_paddr, sizeof(*estatus), 1,
|
|
|
|
fixmap_idx);
|
|
|
|
if (!estatus->block_status) {
|
2019-01-29 18:48:42 +00: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 06:35:20 +00:00
|
|
|
return -ENOENT;
|
2019-01-29 18:48:42 +00: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 06:35:20 +00:00
|
|
|
|
2019-06-25 05:15:28 +00:00
|
|
|
return 0;
|
2019-01-29 18:48:55 +00:00
|
|
|
}
|
2019-01-29 18:48:54 +00:00
|
|
|
|
2019-01-29 18:48:55 +00: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-29 18:48:54 +00:00
|
|
|
if (cper_estatus_check(estatus)) {
|
2019-01-29 18:48:38 +00:00
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
|
|
|
"Failed to read error status block!\n");
|
2019-01-29 18:48:54 +00:00
|
|
|
return -EIO;
|
|
|
|
}
|
2019-01-29 18:48:42 +00:00
|
|
|
|
2019-01-29 18:48:54 +00: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 06:35:20 +00:00
|
|
|
}
|
|
|
|
|
2019-01-29 18:48:55 +00: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-29 18:48:53 +00: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 06:35:20 +00:00
|
|
|
{
|
2019-01-29 18:48:53 +00:00
|
|
|
estatus->block_status = 0;
|
2019-01-29 18:48:42 +00:00
|
|
|
|
|
|
|
if (!buf_paddr)
|
|
|
|
return;
|
|
|
|
|
2019-01-29 18:48:53 +00:00
|
|
|
ghes_copy_tofrom_phys(estatus, buf_paddr,
|
|
|
|
sizeof(estatus->block_status), 0,
|
2019-01-29 18:48:52 +00:00
|
|
|
fixmap_idx);
|
2019-01-29 18:48:46 +00: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 06:35:20 +00:00
|
|
|
}
|
|
|
|
|
2020-05-01 16:45:42 +00: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 12:37:07 +00:00
|
|
|
static bool ghes_do_memory_failure(u64 physical_addr, int flags)
|
2013-07-10 09:27:01 +00:00
|
|
|
{
|
|
|
|
unsigned long pfn;
|
|
|
|
|
2020-05-01 16:45:42 +00:00
|
|
|
if (!IS_ENABLED(CONFIG_ACPI_APEI_MEMORY_FAILURE))
|
|
|
|
return false;
|
|
|
|
|
2021-06-11 12:37:07 +00:00
|
|
|
pfn = PHYS_PFN(physical_addr);
|
2013-11-25 07:15:01 +00:00
|
|
|
if (!pfn_valid(pfn)) {
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
|
|
|
"Invalid address in generic error data: %#llx\n",
|
2021-06-11 12:37:07 +00:00
|
|
|
physical_addr);
|
2020-05-01 16:45:42 +00:00
|
|
|
return false;
|
2013-07-10 09:27:01 +00:00
|
|
|
}
|
2013-11-25 07:15:01 +00:00
|
|
|
|
2021-06-11 12:37:07 +00:00
|
|
|
memory_failure_queue(pfn, flags);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata,
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
int sev, bool sync)
|
2021-06-11 12:37:07 +00:00
|
|
|
{
|
|
|
|
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 07:15:01 +00: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)
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
flags = sync ? MF_ACTION_REQUIRED : 0;
|
2013-11-25 07:15:01 +00:00
|
|
|
|
2021-06-11 12:37:07 +00:00
|
|
|
if (flags != -1)
|
|
|
|
return ghes_do_memory_failure(mem_err->physical_addr, flags);
|
2020-05-01 16:45:42 +00:00
|
|
|
|
|
|
|
return false;
|
2013-07-10 09:27:01 +00:00
|
|
|
}
|
|
|
|
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
static bool ghes_handle_arm_hw_error(struct acpi_hest_generic_data *gdata,
|
|
|
|
int sev, bool sync)
|
2021-06-11 12:37:07 +00:00
|
|
|
{
|
|
|
|
struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata);
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
int flags = sync ? MF_ACTION_REQUIRED : 0;
|
2021-06-11 12:37:07 +00:00
|
|
|
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) {
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
queued = ghes_do_memory_failure(err_info->physical_fault_addr, flags);
|
2021-06-11 12:37:07 +00:00
|
|
|
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-28 21:48:09 +00: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-28 21:48:08 +00:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_ACPI_APEI_PCIEAER
|
|
|
|
struct cper_sec_pcie *pcie_err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2017-11-28 21:48:09 +00:00
|
|
|
if (pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
|
2017-11-28 21:48:08 +00: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 12:34:55 +00: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-01 16:45:42 +00:00
|
|
|
static bool ghes_do_proc(struct ghes *ghes,
|
2014-06-03 08:32:53 +00: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 06:35:20 +00:00
|
|
|
{
|
2011-07-13 05:14:28 +00:00
|
|
|
int sev, sec_sev;
|
2014-06-03 08:32:53 +00:00
|
|
|
struct acpi_hest_generic_data *gdata;
|
2017-06-05 16:40:43 +00:00
|
|
|
guid_t *sec_type;
|
2019-07-17 10:55:43 +00:00
|
|
|
const guid_t *fru_id = &guid_null;
|
2017-06-21 18:17:12 +00:00
|
|
|
char *fru_text = "";
|
2020-05-01 16:45:42 +00:00
|
|
|
bool queued = false;
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
bool sync = is_hest_sync_notify(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 06:35:20 +00: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 05:14:25 +00:00
|
|
|
sev = ghes_severity(estatus->error_severity);
|
|
|
|
apei_estatus_for_each_section(estatus, gdata) {
|
2017-06-05 16:40:43 +00:00
|
|
|
sec_type = (guid_t *)gdata->section_type;
|
2011-07-13 05:14:28 +00:00
|
|
|
sec_sev = ghes_severity(gdata->error_severity);
|
2017-06-21 18:17:12 +00: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-05 16:40:43 +00:00
|
|
|
if (guid_equal(sec_type, &CPER_SEC_PLATFORM_MEM)) {
|
2017-06-21 18:17:05 +00:00
|
|
|
struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2018-04-30 21:33:50 +00:00
|
|
|
ghes_edac_report_mem_error(sev, mem_err);
|
2013-02-15 09:10:39 +00:00
|
|
|
|
2014-07-22 09:20:11 +00:00
|
|
|
arch_apei_report_mem_error(sev, mem_err);
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
queued = ghes_handle_memory_failure(gdata, sev, sync);
|
2011-07-13 05:14:28 +00:00
|
|
|
}
|
2017-06-05 16:40:43 +00:00
|
|
|
else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
|
2017-11-28 21:48:09 +00:00
|
|
|
ghes_handle_aer(gdata);
|
2011-12-08 03:25:41 +00:00
|
|
|
}
|
2017-06-21 18:17:13 +00:00
|
|
|
else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
|
ACPI: APEI: set memory failure flags as MF_ACTION_REQUIRED on synchronous events
[ Upstream commit a70297d2213253853e95f5b49651f924990c6d3b ]
There are two major types of uncorrected recoverable (UCR) errors :
- Synchronous error: The error is detected and raised at the point of
the consumption in the execution flow, e.g. when a CPU tries to
access a poisoned cache line. The CPU will take a synchronous error
exception such as Synchronous External Abort (SEA) on Arm64 and
Machine Check Exception (MCE) on X86. OS requires to take action (for
example, offline failure page/kill failure thread) to recover this
uncorrectable error.
- Asynchronous error: The error is detected out of processor execution
context, e.g. when an error is detected by a background scrubber.
Some data in the memory are corrupted. But the data have not been
consumed. OS is optional to take action to recover this uncorrectable
error.
When APEI firmware first is enabled, a platform may describe one error
source for the handling of synchronous errors (e.g. MCE or SEA notification
), or for handling asynchronous errors (e.g. SCI or External Interrupt
notification). In other words, we can distinguish synchronous errors by
APEI notification. For synchronous errors, kernel will kill the current
process which accessing the poisoned page by sending SIGBUS with
BUS_MCEERR_AR. In addition, for asynchronous errors, kernel will notify the
process who owns the poisoned page by sending SIGBUS with BUS_MCEERR_AO in
early kill mode. However, the GHES driver always sets mf_flags to 0 so that
all synchronous errors are handled as asynchronous errors in memory failure.
To this end, set memory failure flags as MF_ACTION_REQUIRED on synchronous
events.
Signed-off-by: Shuai Xue <xueshuai@linux.alibaba.com>
Tested-by: Ma Wupeng <mawupeng1@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Reviewed-by: Xiaofei Tan <tanxiaofei@huawei.com>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-12-18 06:45:18 +00:00
|
|
|
queued = ghes_handle_arm_hw_error(gdata, sev, sync);
|
2017-06-21 18:17:13 +00:00
|
|
|
} else {
|
2017-06-21 18:17:12 +00:00
|
|
|
void *err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2020-09-03 12:34:55 +00:00
|
|
|
ghes_defer_non_standard_event(gdata, sev);
|
2017-06-21 18:17:12 +00: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 06:35:20 +00:00
|
|
|
}
|
2020-05-01 16:45:42 +00:00
|
|
|
|
|
|
|
return queued;
|
2010-12-07 02:22:31 +00: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 06:35:20 +00: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 05:14:25 +00:00
|
|
|
static void __ghes_print_estatus(const char *pfx,
|
|
|
|
const struct acpi_hest_generic *generic,
|
2014-06-03 08:32:53 +00:00
|
|
|
const struct acpi_hest_generic_status *estatus)
|
2010-12-07 02:22:31 +00:00
|
|
|
{
|
2011-12-08 03:25:44 +00:00
|
|
|
static atomic_t seqno;
|
|
|
|
unsigned int curr_seqno;
|
|
|
|
char pfx_seq[64];
|
|
|
|
|
2010-12-07 02:22:31 +00: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 05:14:25 +00:00
|
|
|
if (ghes_severity(estatus->error_severity) <=
|
2010-12-07 02:22:31 +00:00
|
|
|
GHES_SEV_CORRECTED)
|
2011-12-08 03:25:44 +00:00
|
|
|
pfx = KERN_WARNING;
|
2010-12-07 02:22:31 +00:00
|
|
|
else
|
2011-12-08 03:25:44 +00:00
|
|
|
pfx = KERN_ERR;
|
2010-12-07 02:22:31 +00:00
|
|
|
}
|
2011-12-08 03:25:44 +00:00
|
|
|
curr_seqno = atomic_inc_return(&seqno);
|
|
|
|
snprintf(pfx_seq, sizeof(pfx_seq), "%s{%u}" HW_ERR, pfx, curr_seqno);
|
2011-07-13 05:14:15 +00:00
|
|
|
printk("%s""Hardware error from APEI Generic Hardware Error Source: %d\n",
|
2011-12-08 03:25:44 +00:00
|
|
|
pfx_seq, generic->header.source_id);
|
2013-10-18 21:28:59 +00:00
|
|
|
cper_estatus_print(pfx_seq, estatus);
|
2011-07-13 05:14:15 +00: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 05:14:26 +00:00
|
|
|
static int ghes_print_estatus(const char *pfx,
|
|
|
|
const struct acpi_hest_generic *generic,
|
2014-06-03 08:32:53 +00:00
|
|
|
const struct acpi_hest_generic_status *estatus)
|
2011-07-13 05:14:15 +00: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 05:14:25 +00: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 05:14:15 +00: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 05:14:25 +00: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 05:14:26 +00: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 05:14:25 +00: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 05:14:26 +00: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 08:32:53 +00: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 05:14:26 +00:00
|
|
|
{
|
|
|
|
u32 len;
|
|
|
|
int i, cached = 0;
|
|
|
|
unsigned long long now;
|
|
|
|
struct ghes_estatus_cache *cache;
|
2014-06-03 08:32:53 +00: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 05:14:26 +00:00
|
|
|
|
2013-10-18 21:28:59 +00: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 05:14:26 +00: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 08:32:53 +00: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 05:14:26 +00:00
|
|
|
{
|
|
|
|
int alloced;
|
|
|
|
u32 len, cache_len;
|
|
|
|
struct ghes_estatus_cache *cache;
|
2014-06-03 08:32:53 +00: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 05:14:26 +00: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-18 21:28:59 +00: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 05:14:26 +00: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;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_estatus_cache_free(struct ghes_estatus_cache *cache)
|
|
|
|
{
|
|
|
|
u32 len;
|
|
|
|
|
2013-10-18 21:28:59 +00: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 05:14:26 +00:00
|
|
|
len = GHES_ESTATUS_CACHE_LEN(len);
|
|
|
|
gen_pool_free(ghes_estatus_pool, (unsigned long)cache, len);
|
|
|
|
atomic_dec(&ghes_estatus_cache_alloced);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_estatus_cache_rcu_free(struct rcu_head *head)
|
|
|
|
{
|
|
|
|
struct ghes_estatus_cache *cache;
|
|
|
|
|
|
|
|
cache = container_of(head, struct ghes_estatus_cache, rcu);
|
|
|
|
ghes_estatus_cache_free(cache);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_estatus_cache_add(
|
|
|
|
struct acpi_hest_generic *generic,
|
2014-06-03 08:32:53 +00: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 05:14:26 +00:00
|
|
|
{
|
|
|
|
int i, slot = -1, count;
|
|
|
|
unsigned long long now, duration, period, max_period = 0;
|
|
|
|
struct ghes_estatus_cache *cache, *slot_cache = NULL, *new_cache;
|
|
|
|
|
|
|
|
new_cache = ghes_estatus_cache_alloc(generic, estatus);
|
|
|
|
if (new_cache == NULL)
|
|
|
|
return;
|
|
|
|
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;
|
|
|
|
slot_cache = NULL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
duration = now - cache->time_in;
|
|
|
|
if (duration >= GHES_ESTATUS_IN_CACHE_MAX_NSEC) {
|
|
|
|
slot = i;
|
|
|
|
slot_cache = cache;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
count = atomic_read(&cache->count);
|
2011-08-02 22:00:21 +00: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 05:14:26 +00:00
|
|
|
if (period > max_period) {
|
|
|
|
max_period = period;
|
|
|
|
slot = i;
|
|
|
|
slot_cache = cache;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
/* new_cache must be put into array after its contents are written */
|
|
|
|
smp_wmb();
|
|
|
|
if (slot != -1 && cmpxchg(ghes_estatus_caches + slot,
|
|
|
|
slot_cache, new_cache) == slot_cache) {
|
|
|
|
if (slot_cache)
|
|
|
|
call_rcu(&slot_cache->rcu, ghes_estatus_cache_rcu_free);
|
|
|
|
} else
|
|
|
|
ghes_estatus_cache_free(new_cache);
|
|
|
|
rcu_read_unlock();
|
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 06:35:20 +00:00
|
|
|
}
|
|
|
|
|
2019-01-29 18:48:53 +00:00
|
|
|
static void __ghes_panic(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 buf_paddr, enum fixed_addresses fixmap_idx)
|
2017-06-21 18:17:10 +00:00
|
|
|
{
|
2019-01-29 18:48:53 +00:00
|
|
|
__ghes_print_estatus(KERN_EMERG, ghes->generic, estatus);
|
2017-06-21 18:17:10 +00:00
|
|
|
|
2019-01-29 18:48:53 +00:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);
|
2018-12-19 16:50:52 +00:00
|
|
|
|
2017-06-21 18:17:10 +00: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 06:35:20 +00:00
|
|
|
static int ghes_proc(struct ghes *ghes)
|
|
|
|
{
|
2019-01-29 18:48:53 +00:00
|
|
|
struct acpi_hest_generic_status *estatus = ghes->estatus;
|
2019-01-29 18:48:42 +00: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 06:35:20 +00:00
|
|
|
int rc;
|
|
|
|
|
2019-01-29 18:48:53 +00: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 06:35:20 +00:00
|
|
|
if (rc)
|
|
|
|
goto out;
|
2017-06-21 18:17:10 +00:00
|
|
|
|
2019-01-29 18:48:53 +00:00
|
|
|
if (ghes_severity(estatus->error_severity) >= GHES_SEV_PANIC)
|
|
|
|
__ghes_panic(ghes, estatus, buf_paddr, FIX_APEI_GHES_IRQ);
|
2017-06-21 18:17:10 +00:00
|
|
|
|
2019-01-29 18:48:53 +00: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 05:14:26 +00:00
|
|
|
}
|
2019-01-29 18:48:53 +00:00
|
|
|
ghes_do_proc(ghes, estatus);
|
2017-06-21 18:17:04 +00:00
|
|
|
|
2017-08-28 16:53:41 +00:00
|
|
|
out:
|
2019-01-29 18:48:53 +00:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, FIX_APEI_GHES_IRQ);
|
2017-08-28 16:53:41 +00:00
|
|
|
|
2016-10-18 16:07:19 +00: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 06:35:20 +00: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 06:44:55 +00: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 03:18:25 +00: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 06:44:55 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
expire = jiffies + msecs_to_jiffies(g->notify.poll_interval);
|
|
|
|
ghes->timer.expires = round_jiffies_relative(expire);
|
|
|
|
add_timer(&ghes->timer);
|
|
|
|
}
|
|
|
|
|
2017-10-12 23:19:27 +00: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 06:44:55 +00:00
|
|
|
{
|
2017-10-12 23:19:27 +00:00
|
|
|
struct ghes *ghes = from_timer(ghes, t, timer);
|
2019-01-29 18:48:51 +00: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 06:44:55 +00:00
|
|
|
|
2019-01-29 18:48:51 +00: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 06:44:55 +00:00
|
|
|
ghes_proc(ghes);
|
2019-01-29 18:48:51 +00: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 06:44:55 +00: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-29 18:48:51 +00: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 06:44:55 +00:00
|
|
|
int rc;
|
|
|
|
|
2019-01-29 18:48:51 +00: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 06:44:55 +00:00
|
|
|
rc = ghes_proc(ghes);
|
2019-01-29 18:48:51 +00: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 06:44:55 +00:00
|
|
|
if (rc)
|
|
|
|
return IRQ_NONE;
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2017-05-19 09:39:11 +00: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 06:35:20 +00:00
|
|
|
{
|
|
|
|
struct ghes *ghes;
|
2019-01-29 18:48:51 +00: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 06:35:20 +00:00
|
|
|
int ret = NOTIFY_DONE;
|
|
|
|
|
2019-01-29 18:48:51 +00: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 06:35:20 +00:00
|
|
|
rcu_read_lock();
|
2017-05-19 09:39:11 +00: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 06:35:20 +00:00
|
|
|
if (!ghes_proc(ghes))
|
|
|
|
ret = NOTIFY_OK;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
2019-01-29 18:48:51 +00: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 06:35:20 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-05-19 09:39:11 +00:00
|
|
|
static struct notifier_block ghes_notifier_hed = {
|
|
|
|
.notifier_call = ghes_notify_hed,
|
2014-07-22 09:20:12 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2019-01-29 18:48:47 +00: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 09:20:12 +00: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 05:14:25 +00:00
|
|
|
static void ghes_proc_in_irq(struct irq_work *irq_work)
|
|
|
|
{
|
2011-12-08 03:25:45 +00: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 05:14:25 +00: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 05:14:26 +00:00
|
|
|
struct acpi_hest_generic *generic;
|
2014-06-03 08:32:53 +00:00
|
|
|
struct acpi_hest_generic_status *estatus;
|
2020-05-01 16:45:42 +00: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 05:14:25 +00:00
|
|
|
u32 len, node_len;
|
2020-05-01 16:45:42 +00: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 05:14:25 +00:00
|
|
|
|
2011-12-08 03:25:45 +00: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 05:14:25 +00:00
|
|
|
/*
|
|
|
|
* Because the time order of estatus in list is reversed,
|
|
|
|
* revert it back to proper order.
|
|
|
|
*/
|
2014-07-28 06:50:59 +00: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 05:14:25 +00: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-18 21:28:59 +00: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 05:14:25 +00:00
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(len);
|
2020-05-01 16:45:42 +00: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 05:14:26 +00: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-01 16:45:42 +00:00
|
|
|
|
ACPI: APEI: do not add task_work to kernel thread to avoid memory leak
[ Upstream commit 415fed694fe11395df56e05022d6e7cee1d39dd3 ]
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-09-24 07:49:53 +00:00
|
|
|
if (task_work_pending && current->mm) {
|
2020-05-01 16:45:42 +00: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 15:02:26 +00:00
|
|
|
TWA_RESUME);
|
2020-05-01 16:45:42 +00: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 05:14:25 +00:00
|
|
|
llnode = next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-08 03:25:45 +00: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 08:32:53 +00:00
|
|
|
struct acpi_hest_generic_status *estatus;
|
2011-12-08 03:25:45 +00: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 06:50:59 +00:00
|
|
|
llnode = llist_reverse_order(llnode);
|
2011-12-08 03:25:45 +00: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-29 18:48:56 +00:00
|
|
|
static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
2015-03-18 08:41:35 +00:00
|
|
|
{
|
2019-01-29 18:48:56 +00:00
|
|
|
struct acpi_hest_generic_status *estatus, tmp_header;
|
2015-03-18 08:41:35 +00:00
|
|
|
struct ghes_estatus_node *estatus_node;
|
2019-01-29 18:48:56 +00:00
|
|
|
u32 len, node_len;
|
|
|
|
u64 buf_paddr;
|
|
|
|
int sev, rc;
|
2015-03-18 08:41:35 +00:00
|
|
|
|
2019-01-29 18:48:53 +00:00
|
|
|
if (!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG))
|
2019-01-29 18:48:56 +00:00
|
|
|
return -EOPNOTSUPP;
|
2015-03-18 08:41:35 +00:00
|
|
|
|
2019-01-29 18:48:56 +00: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-29 18:48:53 +00:00
|
|
|
|
2019-01-29 18:48:56 +00: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 08:41:35 +00:00
|
|
|
|
2019-01-29 18:48:56 +00:00
|
|
|
len = cper_estatus_len(&tmp_header);
|
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(len);
|
2015-03-18 08:41:35 +00:00
|
|
|
estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
|
|
|
|
if (!estatus_node)
|
2019-01-29 18:48:56 +00:00
|
|
|
return -ENOMEM;
|
2015-03-18 08:41:35 +00:00
|
|
|
|
|
|
|
estatus_node->ghes = ghes;
|
|
|
|
estatus_node->generic = ghes->generic;
|
2020-05-01 16:45:42 +00:00
|
|
|
estatus_node->task_work.func = NULL;
|
2015-03-18 08:41:35 +00:00
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
|
|
|
|
2019-01-29 18:48:56 +00:00
|
|
|
if (__ghes_read_estatus(estatus, buf_paddr, fixmap_idx, len)) {
|
2019-01-29 18:48:53 +00:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);
|
2019-01-29 18:48:56 +00:00
|
|
|
rc = -ENOENT;
|
|
|
|
goto no_work;
|
2019-01-29 18:48:45 +00:00
|
|
|
}
|
2015-03-27 09:05:00 +00:00
|
|
|
|
2019-01-29 18:48:53 +00:00
|
|
|
sev = ghes_severity(estatus->error_severity);
|
2019-01-29 18:48:45 +00:00
|
|
|
if (sev >= GHES_SEV_PANIC) {
|
|
|
|
ghes_print_queued_estatus();
|
2019-01-29 18:48:53 +00:00
|
|
|
__ghes_panic(ghes, estatus, buf_paddr, fixmap_idx);
|
2019-01-29 18:48:45 +00:00
|
|
|
}
|
2015-03-18 08:55:21 +00:00
|
|
|
|
2019-01-29 18:48:56 +00:00
|
|
|
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
|
2015-03-18 08:55:21 +00:00
|
|
|
|
2019-01-29 18:48:56 +00: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-29 18:48:45 +00:00
|
|
|
}
|
|
|
|
|
2019-01-29 18:48:52 +00:00
|
|
|
static int ghes_in_nmi_spool_from_list(struct list_head *rcu_list,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
2019-01-29 18:48:45 +00:00
|
|
|
{
|
|
|
|
int ret = -ENOENT;
|
|
|
|
struct ghes *ghes;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(ghes, rcu_list, list) {
|
2019-01-29 18:48:52 +00:00
|
|
|
if (!ghes_in_nmi_queue_one_entry(ghes, fixmap_idx))
|
2019-01-29 18:48:45 +00: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 06:44:55 +00:00
|
|
|
}
|
2019-01-29 18:48:45 +00:00
|
|
|
rcu_read_unlock();
|
2015-03-18 08:41:35 +00:00
|
|
|
|
2019-01-29 18:48:45 +00:00
|
|
|
if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && !ret)
|
2016-11-30 13:19:39 +00:00
|
|
|
irq_work_queue(&ghes_proc_irq_work);
|
2019-01-29 18:48:45 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2019-01-29 18:48:47 +00: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-29 18:48:51 +00:00
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_notify_lock_sea);
|
|
|
|
int rv;
|
|
|
|
|
|
|
|
raw_spin_lock(&ghes_notify_lock_sea);
|
2019-01-29 18:48:57 +00:00
|
|
|
rv = ghes_in_nmi_spool_from_list(&ghes_sea, FIX_APEI_GHES_SEA);
|
2019-01-29 18:48:51 +00:00
|
|
|
raw_spin_unlock(&ghes_notify_lock_sea);
|
|
|
|
|
|
|
|
return rv;
|
2019-01-29 18:48:47 +00: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-29 18:48:45 +00:00
|
|
|
|
|
|
|
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
|
|
|
|
{
|
2019-01-29 18:48:51 +00:00
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_notify_lock_nmi);
|
2019-01-29 18:48:45 +00:00
|
|
|
int ret = NMI_DONE;
|
|
|
|
|
|
|
|
if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
|
|
|
|
return ret;
|
|
|
|
|
2019-01-29 18:48:51 +00:00
|
|
|
raw_spin_lock(&ghes_notify_lock_nmi);
|
2019-01-29 18:48:52 +00:00
|
|
|
if (!ghes_in_nmi_spool_from_list(&ghes_nmi, FIX_APEI_GHES_NMI))
|
2019-01-29 18:48:45 +00:00
|
|
|
ret = NMI_HANDLED;
|
2019-01-29 18:48:51 +00:00
|
|
|
raw_spin_unlock(&ghes_notify_lock_nmi);
|
2019-01-29 18:48:45 +00:00
|
|
|
|
2015-03-27 09:05:00 +00: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 06:44:55 +00:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-07-22 09:20:12 +00: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-29 18:48:48 +00: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 09:20:12 +00:00
|
|
|
|
|
|
|
static void ghes_nmi_init_cxt(void)
|
|
|
|
{
|
|
|
|
init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
|
|
|
|
}
|
|
|
|
|
2019-01-29 18:49:02 +00: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-19 18:22:46 +00: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 06:35:20 +00:00
|
|
|
{
|
|
|
|
struct acpi_hest_generic *generic;
|
|
|
|
struct ghes *ghes = NULL;
|
2019-01-29 18:48:51 +00:00
|
|
|
unsigned long flags;
|
2014-07-22 09:20:12 +00:00
|
|
|
|
2010-08-02 07:48:24 +00: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 06:35:20 +00:00
|
|
|
|
2010-09-29 11:53:53 +00: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 06:35:20 +00:00
|
|
|
if (!generic->enabled)
|
2010-08-02 07:48:24 +00: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 06:35:20 +00: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 06:44:55 +00:00
|
|
|
switch (generic->notify.type) {
|
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 09:39:11 +00:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2014-07-22 09:20:12 +00:00
|
|
|
break;
|
2017-05-19 09:39:11 +00:00
|
|
|
|
2017-06-21 18:17:09 +00: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 06:44:55 +00:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 09:20:12 +00: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 06:44:55 +00:00
|
|
|
break;
|
2019-01-29 18:49:02 +00: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 06:44:55 +00:00
|
|
|
case ACPI_HEST_NOTIFY_LOCAL:
|
2019-10-18 03:18:25 +00: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 06:35:20 +00: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 06:44:55 +00:00
|
|
|
default:
|
2019-10-18 03:18:25 +00: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 06:44:55 +00: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 06:35:20 +00: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 06:44:55 +00:00
|
|
|
|
|
|
|
rc = -EIO;
|
|
|
|
if (generic->error_block_length <
|
2014-06-03 08:32:53 +00:00
|
|
|
sizeof(struct acpi_hest_generic_status)) {
|
2019-10-18 03:18:25 +00: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 06:35:20 +00:00
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
ghes = ghes_new(generic);
|
|
|
|
if (IS_ERR(ghes)) {
|
|
|
|
rc = PTR_ERR(ghes);
|
|
|
|
ghes = NULL;
|
|
|
|
goto err;
|
|
|
|
}
|
2013-02-15 09:10:39 +00: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 06:44:55 +00:00
|
|
|
switch (generic->notify.type) {
|
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
2020-01-08 17:17:38 +00: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 06:44:55 +00:00
|
|
|
ghes_add_timer(ghes);
|
|
|
|
break;
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
/* External interrupt vector is GSI */
|
2013-06-03 02:08:39 +00: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 06:44:55 +00: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 12:16:46 +00: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 06:44:55 +00:00
|
|
|
}
|
2017-07-21 18:24:37 +00:00
|
|
|
rc = request_irq(ghes->irq, ghes_irq_func, IRQF_SHARED,
|
|
|
|
"GHES IRQ", ghes);
|
2013-06-03 02:08:39 +00: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 06:44:55 +00:00
|
|
|
pr_err(GHES_PFX "Failed to register IRQ for generic hardware error source: %d\n",
|
|
|
|
generic->header.source_id);
|
2018-04-23 12:16:46 +00: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 06:44:55 +00:00
|
|
|
}
|
|
|
|
break;
|
2017-05-19 09:39:11 +00: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 06:44:55 +00:00
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 09:39:11 +00:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2010-08-02 07:48:24 +00:00
|
|
|
mutex_lock(&ghes_list_mutex);
|
2017-05-19 09:39:11 +00:00
|
|
|
if (list_empty(&ghes_hed))
|
|
|
|
register_acpi_hed_notifier(&ghes_notifier_hed);
|
|
|
|
list_add_rcu(&ghes->list, &ghes_hed);
|
2010-08-02 07:48:24 +00: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 06:44:55 +00:00
|
|
|
break;
|
2017-05-19 09:39:11 +00:00
|
|
|
|
2017-06-21 18:17:09 +00: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 06:44:55 +00:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 09:20:12 +00: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 06:44:55 +00:00
|
|
|
break;
|
2019-01-29 18:49:02 +00: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 06:44:55 +00: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 06:35:20 +00:00
|
|
|
}
|
2018-04-23 12:16:46 +00:00
|
|
|
|
2010-08-02 07:48:24 +00: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 06:35:20 +00:00
|
|
|
|
2018-04-23 12:16:46 +00:00
|
|
|
ghes_edac_register(ghes, &ghes_dev->dev);
|
|
|
|
|
2017-06-21 18:17:15 +00:00
|
|
|
/* Handle any pending errors right away */
|
2019-01-29 18:48:51 +00:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
2017-06-21 18:17:15 +00:00
|
|
|
ghes_proc(ghes);
|
2019-01-29 18:48:51 +00:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
2017-06-21 18:17:15 +00: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 06:35:20 +00:00
|
|
|
return 0;
|
2018-04-23 12:16:46 +00: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 06:35:20 +00:00
|
|
|
err:
|
2010-08-02 07:48:24 +00: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 06:35:20 +00:00
|
|
|
ghes_fini(ghes);
|
2010-08-02 07:48:24 +00: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 06:35:20 +00:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2012-11-21 22:13:09 +00: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 06:35:20 +00:00
|
|
|
{
|
2019-01-29 18:49:02 +00:00
|
|
|
int rc;
|
2010-08-02 07:48:24 +00: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 06:35:20 +00:00
|
|
|
|
2010-08-02 07:48:24 +00: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 06:44:55 +00:00
|
|
|
ghes->flags |= GHES_EXITING;
|
2010-08-02 07:48:24 +00: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 06:44:55 +00:00
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
|
|
|
del_timer_sync(&ghes->timer);
|
|
|
|
break;
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
free_irq(ghes->irq, ghes);
|
|
|
|
break;
|
2017-05-19 09:39:11 +00:00
|
|
|
|
2010-08-02 07:48:24 +00:00
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 09:39:11 +00:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2010-08-02 07:48:24 +00:00
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_del_rcu(&ghes->list);
|
2017-05-19 09:39:11 +00:00
|
|
|
if (list_empty(&ghes_hed))
|
|
|
|
unregister_acpi_hed_notifier(&ghes_notifier_hed);
|
2010-08-02 07:48:24 +00:00
|
|
|
mutex_unlock(&ghes_list_mutex);
|
2017-03-16 14:30:39 +00:00
|
|
|
synchronize_rcu();
|
2010-08-02 07:48:24 +00:00
|
|
|
break;
|
2017-05-19 09:39:11 +00:00
|
|
|
|
2017-06-21 18:17:09 +00: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 06:44:55 +00:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 09:20:12 +00: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 06:44:55 +00:00
|
|
|
break;
|
2019-01-29 18:49:02 +00:00
|
|
|
case ACPI_HEST_NOTIFY_SOFTWARE_DELEGATED:
|
|
|
|
rc = apei_sdei_unregister_ghes(ghes);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
break;
|
2010-08-02 07:48:24 +00: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 06:35:20 +00:00
|
|
|
|
2010-08-02 07:48:24 +00:00
|
|
|
ghes_fini(ghes);
|
2013-02-15 09:10:39 +00:00
|
|
|
|
|
|
|
ghes_edac_unregister(ghes);
|
|
|
|
|
2010-08-02 07:48:24 +00: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 06:35:20 +00:00
|
|
|
|
2010-08-02 07:48:24 +00:00
|
|
|
platform_set_drvdata(ghes_dev, NULL);
|
|
|
|
|
|
|
|
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 06:35:20 +00:00
|
|
|
}
|
|
|
|
|
2010-08-02 07:48:24 +00:00
|
|
|
static struct platform_driver ghes_platform_driver = {
|
|
|
|
.driver = {
|
|
|
|
.name = "GHES",
|
|
|
|
},
|
|
|
|
.probe = ghes_probe,
|
|
|
|
.remove = ghes_remove,
|
|
|
|
};
|
|
|
|
|
2022-02-27 12:25:45 +00:00
|
|
|
void __init 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 06:35:20 +00: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 06:44:55 +00:00
|
|
|
int rc;
|
|
|
|
|
2022-02-27 12:25:45 +00: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 06:35:20 +00:00
|
|
|
if (acpi_disabled)
|
2022-02-27 12:25:45 +00: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 06:35:20 +00:00
|
|
|
|
2017-08-29 13:20:20 +00:00
|
|
|
switch (hest_disable) {
|
|
|
|
case HEST_NOT_FOUND:
|
2022-02-27 12:25:45 +00:00
|
|
|
return;
|
2017-08-29 13:20:20 +00: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 06:35:20 +00:00
|
|
|
pr_info(GHES_PFX "HEST is not enabled!\n");
|
2022-02-27 12:25:45 +00:00
|
|
|
return;
|
2017-08-29 13:20:20 +00: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 06:35:20 +00:00
|
|
|
}
|
|
|
|
|
2011-07-13 05:14:19 +00:00
|
|
|
if (ghes_disable) {
|
|
|
|
pr_info(GHES_PFX "GHES is not enabled!\n");
|
2022-02-27 12:25:45 +00:00
|
|
|
return;
|
2011-07-13 05:14:19 +00:00
|
|
|
}
|
|
|
|
|
2014-07-22 09:20:12 +00: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 05:14:25 +00:00
|
|
|
|
|
|
|
rc = platform_driver_register(&ghes_platform_driver);
|
|
|
|
if (rc)
|
2022-02-27 12:25:45 +00: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 05:14:25 +00:00
|
|
|
|
2011-07-13 05:14:21 +00: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 06:35:20 +00:00
|
|
|
}
|