ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
/*
|
|
|
|
* APEI Generic Hardware Error Source support
|
|
|
|
*
|
|
|
|
* Generic Hardware Error Source provides a way to report platform
|
|
|
|
* hardware errors (such as that from chipset). It works in so called
|
|
|
|
* "Firmware First" mode, that is, hardware errors are reported to
|
|
|
|
* firmware firstly, then reported to Linux by firmware. This way,
|
|
|
|
* some non-standard hardware error registers or non-standard hardware
|
|
|
|
* link can be checked by firmware to produce more hardware error
|
|
|
|
* information for Linux.
|
|
|
|
*
|
|
|
|
* For more information about Generic Hardware Error Source, please
|
|
|
|
* refer to ACPI Specification version 4.0, section 17.3.2.6
|
|
|
|
*
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
* Copyright 2010,2011 Intel Corp.
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
* Author: Huang Ying <ying.huang@intel.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License version
|
|
|
|
* 2 as published by the Free Software Foundation;
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
2016-02-15 13:27:50 +08:00
|
|
|
#include <linux/moduleparam.h>
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/acpi.h>
|
|
|
|
#include <linux/io.h>
|
|
|
|
#include <linux/interrupt.h>
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
#include <linux/timer.h>
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
#include <linux/cper.h>
|
2010-08-02 15:48:24 +08:00
|
|
|
#include <linux/platform_device.h>
|
|
|
|
#include <linux/mutex.h>
|
2010-12-07 10:22:31 +08:00
|
|
|
#include <linux/ratelimit.h>
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
#include <linux/vmalloc.h>
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
#include <linux/irq_work.h>
|
|
|
|
#include <linux/llist.h>
|
|
|
|
#include <linux/genalloc.h>
|
2011-12-08 11:25:41 +08:00
|
|
|
#include <linux/pci.h>
|
2019-01-30 02:48:52 +08:00
|
|
|
#include <linux/pfn.h>
|
2011-12-08 11:25:41 +08:00
|
|
|
#include <linux/aer.h>
|
2014-07-22 17:20:12 +08:00
|
|
|
#include <linux/nmi.h>
|
2017-02-01 23:36:40 +08:00
|
|
|
#include <linux/sched/clock.h>
|
2017-06-22 02:17:12 +08:00
|
|
|
#include <linux/uuid.h>
|
|
|
|
#include <linux/ras.h>
|
2013-02-15 16:41:22 +08:00
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
#include <acpi/actbl1.h>
|
2013-02-15 16:41:22 +08:00
|
|
|
#include <acpi/ghes.h>
|
2014-07-22 17:20:11 +08:00
|
|
|
#include <acpi/apei.h>
|
2017-11-07 02:44:24 +08:00
|
|
|
#include <asm/fixmap.h>
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
#include <asm/tlbflush.h>
|
2017-06-22 02:17:12 +08:00
|
|
|
#include <ras/ras_event.h>
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
|
|
|
#include "apei-internal.h"
|
|
|
|
|
|
|
|
#define GHES_PFX "GHES: "
|
|
|
|
|
|
|
|
#define GHES_ESTATUS_MAX_SIZE 65536
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
#define GHES_ESOURCE_PREALLOC_MAX_SIZE 65536
|
|
|
|
|
|
|
|
#define GHES_ESTATUS_POOL_MIN_ALLOC_ORDER 3
|
|
|
|
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
/* This is just an estimation for memory pool allocation */
|
|
|
|
#define GHES_ESTATUS_CACHE_AVG_SIZE 512
|
|
|
|
|
|
|
|
#define GHES_ESTATUS_CACHES_SIZE 4
|
|
|
|
|
2011-08-03 06:00:21 +08:00
|
|
|
#define GHES_ESTATUS_IN_CACHE_MAX_NSEC 10000000000ULL
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
/* Prevent too many caches are allocated because of RCU */
|
|
|
|
#define GHES_ESTATUS_CACHE_ALLOCED_MAX (GHES_ESTATUS_CACHES_SIZE * 3 / 2)
|
|
|
|
|
|
|
|
#define GHES_ESTATUS_CACHE_LEN(estatus_len) \
|
|
|
|
(sizeof(struct ghes_estatus_cache) + (estatus_len))
|
|
|
|
#define GHES_ESTATUS_FROM_CACHE(estatus_cache) \
|
2014-06-03 16:32:53 +08:00
|
|
|
((struct acpi_hest_generic_status *) \
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
((struct ghes_estatus_cache *)(estatus_cache) + 1))
|
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
#define GHES_ESTATUS_NODE_LEN(estatus_len) \
|
|
|
|
(sizeof(struct ghes_estatus_node) + (estatus_len))
|
2013-10-19 05:28:59 +08:00
|
|
|
#define GHES_ESTATUS_FROM_NODE(estatus_node) \
|
2014-06-03 16:32:53 +08:00
|
|
|
((struct acpi_hest_generic_status *) \
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
((struct ghes_estatus_node *)(estatus_node) + 1))
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
static inline bool is_hest_type_generic_v2(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
return ghes->generic->header.type == ACPI_HEST_TYPE_GENERIC_ERROR_V2;
|
|
|
|
}
|
|
|
|
|
2016-02-15 13:27:50 +08:00
|
|
|
/*
|
|
|
|
* This driver isn't really modular, however for the time being,
|
|
|
|
* continuing to use module_param is the easiest way to remain
|
|
|
|
* compatible with existing boot arg use cases.
|
|
|
|
*/
|
2012-01-13 07:02:20 +08:00
|
|
|
bool ghes_disable;
|
2011-07-13 13:14:19 +08:00
|
|
|
module_param_named(disable, ghes_disable, bool, 0);
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
/*
|
2017-05-19 17:39:11 +08:00
|
|
|
* All error sources notified with HED (Hardware Error Device) share a
|
|
|
|
* single notifier callback, so they need to be linked and checked one
|
|
|
|
* by one. This holds true for NMI too.
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
*
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
* RCU is used for these lists, so ghes_list_mutex is only used for
|
|
|
|
* list changing, not for traversing.
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
*/
|
2017-05-19 17:39:11 +08:00
|
|
|
static LIST_HEAD(ghes_hed);
|
2010-08-02 15:48:24 +08:00
|
|
|
static DEFINE_MUTEX(ghes_list_mutex);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
/*
|
|
|
|
* Because the memory area used to transfer hardware error information
|
|
|
|
* from BIOS to Linux can be determined only in NMI, IRQ or timer
|
|
|
|
* handler, but general ioremap can not be used in atomic context, so
|
2017-11-07 02:44:24 +08:00
|
|
|
* the fixmap is used instead.
|
2017-11-07 02:44:25 +08:00
|
|
|
*
|
2019-01-30 02:48:51 +08:00
|
|
|
* This spinlock is used to prevent the fixmap entry from being used
|
2017-11-07 02:44:24 +08:00
|
|
|
* simultaneously.
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
*/
|
2019-01-30 02:48:51 +08:00
|
|
|
static DEFINE_SPINLOCK(ghes_notify_lock_irq);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
static struct gen_pool *ghes_estatus_pool;
|
|
|
|
static unsigned long ghes_estatus_pool_size_request;
|
|
|
|
|
2014-09-29 19:33:17 +08: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 13:14:26 +08:00
|
|
|
static atomic_t ghes_estatus_cache_alloced;
|
|
|
|
|
2017-06-22 02:17:10 +08:00
|
|
|
static int ghes_panic_timeout __read_mostly = 30;
|
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
static void __iomem *ghes_map(u64 pfn, enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
{
|
2017-06-22 02:17:09 +08:00
|
|
|
phys_addr_t paddr;
|
|
|
|
pgprot_t prot;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
paddr = PFN_PHYS(pfn);
|
2017-06-22 02:17:09 +08:00
|
|
|
prot = arch_apei_get_mem_attribute(paddr);
|
2019-01-30 02:48:52 +08:00
|
|
|
__set_fixmap(fixmap_idx, paddr, prot);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
return (void __iomem *) __fix_to_virt(fixmap_idx);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
static void ghes_unmap(void __iomem *vaddr, enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
{
|
2019-01-30 02:48:52 +08:00
|
|
|
int _idx = virt_to_fix((unsigned long)vaddr);
|
acpi/apei: Use appropriate pgprot_t to map GHES memory
If the ACPI APEI firmware handles hardware error first (called
"firmware first handling"), the firmware updates the GHES memory
region with hardware error record (called "generic hardware
error record"). Essentially the firmware writes hardware error
records in the GHES memory region, triggers an NMI/interrupt,
then the GHES driver goes off and grabs the error record from
the GHES region.
The kernel currently maps the GHES memory region as cacheable
(PAGE_KERNEL) for all architectures. However, on some arm64
platforms, there is a mismatch between how the kernel maps the
GHES region (PAGE_KERNEL) and how the firmware maps it
(EFI_MEMORY_UC, ie. uncacheable), leading to the possibility of
the kernel GHES driver reading stale data from the cache when it
receives the interrupt.
With stale data being read, the kernel is unaware there is new
hardware error to be handled when there actually is; this may
lead to further damage in various scenarios, such as error
propagation caused data corruption. If uncorrected error (such
as double bit ECC error) happened in memory operation and if the
kernel is unaware of such an event happening, errorneous data may
be propagated to the disk.
Instead GHES memory region should be mapped with page protection
type according to what is returned from arch_apei_get_mem_attribute().
Signed-off-by: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
[ Small stylistic tweaks. ]
Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk>
Acked-by: Borislav Petkov <bp@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1441372302-23242-3-git-send-email-matt@codeblueprint.co.uk
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-04 21:11:42 +08:00
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
WARN_ON_ONCE(fixmap_idx != _idx);
|
|
|
|
clear_fixmap(fixmap_idx);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:41 +08:00
|
|
|
int ghes_estatus_pool_init(int num_ghes)
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
{
|
2019-01-30 02:48:41 +08:00
|
|
|
unsigned long addr, len;
|
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
ghes_estatus_pool = gen_pool_create(GHES_ESTATUS_POOL_MIN_ALLOC_ORDER, -1);
|
|
|
|
if (!ghes_estatus_pool)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-01-30 02:48:41 +08:00
|
|
|
len = GHES_ESTATUS_CACHE_AVG_SIZE * GHES_ESTATUS_CACHE_ALLOCED_MAX;
|
|
|
|
len += (num_ghes * GHES_ESOURCE_PREALLOC_MAX_SIZE);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
|
2019-01-30 02:48:41 +08:00
|
|
|
ghes_estatus_pool_size_request = PAGE_ALIGN(len);
|
2019-01-30 02:48:39 +08:00
|
|
|
addr = (unsigned long)vmalloc(PAGE_ALIGN(len));
|
|
|
|
if (!addr)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* New allocation must be visible in all pgd before it can be found by
|
|
|
|
* an NMI allocating from the pool.
|
|
|
|
*/
|
|
|
|
vmalloc_sync_all();
|
|
|
|
|
|
|
|
return gen_pool_add(ghes_estatus_pool, addr, PAGE_ALIGN(len), -1);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
}
|
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
static int map_gen_v2(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
return apei_map_generic_address(&ghes->generic_v2->read_ack_register);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void unmap_gen_v2(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
apei_unmap_generic_address(&ghes->generic_v2->read_ack_register);
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:46 +08:00
|
|
|
static void ghes_ack_error(struct acpi_hest_generic_v2 *gv2)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
u64 val = 0;
|
|
|
|
|
|
|
|
rc = apei_read(&val, &gv2->read_ack_register);
|
|
|
|
if (rc)
|
|
|
|
return;
|
|
|
|
|
|
|
|
val &= gv2->read_ack_preserve << gv2->read_ack_register.bit_offset;
|
|
|
|
val |= gv2->read_ack_write << gv2->read_ack_register.bit_offset;
|
|
|
|
|
|
|
|
apei_write(val, &gv2->read_ack_register);
|
|
|
|
}
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
static struct ghes *ghes_new(struct acpi_hest_generic *generic)
|
|
|
|
{
|
|
|
|
struct ghes *ghes;
|
|
|
|
unsigned int error_block_length;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
ghes = kzalloc(sizeof(*ghes), GFP_KERNEL);
|
|
|
|
if (!ghes)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
2017-06-22 02:17:04 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
ghes->generic = generic;
|
2017-06-22 02:17:04 +08:00
|
|
|
if (is_hest_type_generic_v2(ghes)) {
|
|
|
|
rc = map_gen_v2(ghes);
|
|
|
|
if (rc)
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
2012-06-12 11:20:19 +08:00
|
|
|
rc = apei_map_generic_address(&generic->error_status_address);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (rc)
|
2017-06-22 02:17:04 +08:00
|
|
|
goto err_unmap_read_ack_addr;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
error_block_length = generic->error_block_length;
|
|
|
|
if (error_block_length > GHES_ESTATUS_MAX_SIZE) {
|
|
|
|
pr_warning(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);
|
|
|
|
error_block_length = GHES_ESTATUS_MAX_SIZE;
|
|
|
|
}
|
|
|
|
ghes->estatus = kmalloc(error_block_length, GFP_KERNEL);
|
|
|
|
if (!ghes->estatus) {
|
|
|
|
rc = -ENOMEM;
|
2017-06-22 02:17:04 +08:00
|
|
|
goto err_unmap_status_addr;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
return ghes;
|
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
err_unmap_status_addr:
|
2012-06-12 11:20:19 +08:00
|
|
|
apei_unmap_generic_address(&generic->error_status_address);
|
2017-06-22 02:17:04 +08:00
|
|
|
err_unmap_read_ack_addr:
|
|
|
|
if (is_hest_type_generic_v2(ghes))
|
|
|
|
unmap_gen_v2(ghes);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
err_free:
|
|
|
|
kfree(ghes);
|
|
|
|
return ERR_PTR(rc);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_fini(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
kfree(ghes->estatus);
|
2012-06-12 11:20:19 +08:00
|
|
|
apei_unmap_generic_address(&ghes->generic->error_status_address);
|
2017-06-22 02:17:04 +08:00
|
|
|
if (is_hest_type_generic_v2(ghes))
|
|
|
|
unmap_gen_v2(ghes);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static inline int ghes_severity(int severity)
|
|
|
|
{
|
|
|
|
switch (severity) {
|
2010-08-02 15:48:23 +08:00
|
|
|
case CPER_SEV_INFORMATIONAL:
|
|
|
|
return GHES_SEV_NO;
|
|
|
|
case CPER_SEV_CORRECTED:
|
|
|
|
return GHES_SEV_CORRECTED;
|
|
|
|
case CPER_SEV_RECOVERABLE:
|
|
|
|
return GHES_SEV_RECOVERABLE;
|
|
|
|
case CPER_SEV_FATAL:
|
|
|
|
return GHES_SEV_PANIC;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
default:
|
2011-03-31 09:57:33 +08:00
|
|
|
/* Unknown, go panic */
|
2010-08-02 15:48:23 +08:00
|
|
|
return GHES_SEV_PANIC;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
static void ghes_copy_tofrom_phys(void *buffer, u64 paddr, u32 len,
|
2019-01-30 02:48:52 +08:00
|
|
|
int from_phys,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
void __iomem *vaddr;
|
|
|
|
u64 offset;
|
|
|
|
u32 trunk;
|
|
|
|
|
|
|
|
while (len > 0) {
|
|
|
|
offset = paddr - (paddr & PAGE_MASK);
|
2019-01-30 02:48:52 +08:00
|
|
|
vaddr = ghes_map(PHYS_PFN(paddr), fixmap_idx);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
trunk = PAGE_SIZE - offset;
|
|
|
|
trunk = min(trunk, len);
|
|
|
|
if (from_phys)
|
|
|
|
memcpy_fromio(buffer, vaddr + offset, trunk);
|
|
|
|
else
|
|
|
|
memcpy_toio(vaddr + offset, buffer, trunk);
|
|
|
|
len -= trunk;
|
|
|
|
paddr += trunk;
|
|
|
|
buffer += trunk;
|
2019-01-30 02:48:52 +08:00
|
|
|
ghes_unmap(vaddr, fixmap_idx);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:54 +08:00
|
|
|
/* Check the top-level record header has an appropriate size. */
|
|
|
|
static int __ghes_check_estatus(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus)
|
|
|
|
{
|
|
|
|
u32 len = cper_estatus_len(estatus);
|
|
|
|
|
|
|
|
if (len < sizeof(*estatus)) {
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX "Truncated error status block!\n");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (len > ghes->generic->error_block_length) {
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid error status block length!\n");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cper_estatus_check_header(estatus)) {
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX "Invalid CPER header!\n");
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:55 +08:00
|
|
|
/* Read the CPER block, returning its address, and header in estatus. */
|
|
|
|
static int __ghes_peek_estatus(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 *buf_paddr, enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
|
|
|
struct acpi_hest_generic *g = ghes->generic;
|
|
|
|
int rc;
|
|
|
|
|
2019-01-30 02:48:42 +08:00
|
|
|
rc = apei_read(buf_paddr, &g->error_status_address);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (rc) {
|
2019-01-30 02:48:42 +08:00
|
|
|
*buf_paddr = 0;
|
2019-01-30 02:48:38 +08:00
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
"Failed to read error status block address for hardware error source: %d.\n",
|
|
|
|
g->header.source_id);
|
|
|
|
return -EIO;
|
|
|
|
}
|
2019-01-30 02:48:42 +08:00
|
|
|
if (!*buf_paddr)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
return -ENOENT;
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_copy_tofrom_phys(estatus, *buf_paddr, sizeof(*estatus), 1,
|
|
|
|
fixmap_idx);
|
|
|
|
if (!estatus->block_status) {
|
2019-01-30 02:48:42 +08:00
|
|
|
*buf_paddr = 0;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
return -ENOENT;
|
2019-01-30 02:48:42 +08:00
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2019-01-30 02:48:55 +08:00
|
|
|
return __ghes_check_estatus(ghes, estatus);
|
|
|
|
}
|
2019-01-30 02:48:54 +08:00
|
|
|
|
2019-01-30 02:48:55 +08:00
|
|
|
static int __ghes_read_estatus(struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 buf_paddr, enum fixed_addresses fixmap_idx,
|
|
|
|
size_t buf_len)
|
|
|
|
{
|
|
|
|
ghes_copy_tofrom_phys(estatus, buf_paddr, buf_len, 1, fixmap_idx);
|
2019-01-30 02:48:54 +08:00
|
|
|
if (cper_estatus_check(estatus)) {
|
2019-01-30 02:48:38 +08:00
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
|
|
|
"Failed to read error status block!\n");
|
2019-01-30 02:48:54 +08:00
|
|
|
return -EIO;
|
|
|
|
}
|
2019-01-30 02:48:42 +08:00
|
|
|
|
2019-01-30 02:48:54 +08:00
|
|
|
return 0;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:55 +08:00
|
|
|
static int ghes_read_estatus(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 *buf_paddr, enum fixed_addresses fixmap_idx)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = __ghes_peek_estatus(ghes, estatus, buf_paddr, fixmap_idx);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
rc = __ghes_check_estatus(ghes, estatus);
|
|
|
|
if (rc)
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
return __ghes_read_estatus(estatus, *buf_paddr, fixmap_idx,
|
|
|
|
cper_estatus_len(estatus));
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
static void ghes_clear_estatus(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 buf_paddr, enum fixed_addresses fixmap_idx)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
2019-01-30 02:48:53 +08:00
|
|
|
estatus->block_status = 0;
|
2019-01-30 02:48:42 +08:00
|
|
|
|
|
|
|
if (!buf_paddr)
|
|
|
|
return;
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_copy_tofrom_phys(estatus, buf_paddr,
|
|
|
|
sizeof(estatus->block_status), 0,
|
2019-01-30 02:48:52 +08:00
|
|
|
fixmap_idx);
|
2019-01-30 02:48:46 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* GHESv2 type HEST entries introduce support for error acknowledgment,
|
|
|
|
* so only acknowledge the error if this support is present.
|
|
|
|
*/
|
|
|
|
if (is_hest_type_generic_v2(ghes))
|
|
|
|
ghes_ack_error(ghes->generic_v2);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2014-06-03 16:32:53 +08:00
|
|
|
static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, int sev)
|
2013-07-10 17:27:01 +08:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_ACPI_APEI_MEMORY_FAILURE
|
|
|
|
unsigned long pfn;
|
2013-11-25 15:15:01 +08:00
|
|
|
int flags = -1;
|
2013-07-10 17:27:01 +08:00
|
|
|
int sec_sev = ghes_severity(gdata->error_severity);
|
2017-06-22 02:17:05 +08:00
|
|
|
struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata);
|
2013-07-10 17:27:01 +08:00
|
|
|
|
2013-11-25 15:15:01 +08:00
|
|
|
if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
|
|
|
|
return;
|
|
|
|
|
|
|
|
pfn = mem_err->physical_addr >> PAGE_SHIFT;
|
|
|
|
if (!pfn_valid(pfn)) {
|
|
|
|
pr_warn_ratelimited(FW_WARN GHES_PFX
|
|
|
|
"Invalid address in generic error data: %#llx\n",
|
|
|
|
mem_err->physical_addr);
|
|
|
|
return;
|
2013-07-10 17:27:01 +08:00
|
|
|
}
|
2013-11-25 15:15:01 +08:00
|
|
|
|
|
|
|
/* iff following two events can be handled properly by now */
|
|
|
|
if (sec_sev == GHES_SEV_CORRECTED &&
|
|
|
|
(gdata->flags & CPER_SEC_ERROR_THRESHOLD_EXCEEDED))
|
|
|
|
flags = MF_SOFT_OFFLINE;
|
|
|
|
if (sev == GHES_SEV_RECOVERABLE && sec_sev == GHES_SEV_RECOVERABLE)
|
|
|
|
flags = 0;
|
|
|
|
|
|
|
|
if (flags != -1)
|
2017-07-10 07:14:01 +08:00
|
|
|
memory_failure_queue(pfn, flags);
|
2013-07-10 17:27:01 +08:00
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2017-11-29 05:48:09 +08:00
|
|
|
/*
|
|
|
|
* PCIe AER errors need to be sent to the AER driver for reporting and
|
|
|
|
* recovery. The GHES severities map to the following AER severities and
|
|
|
|
* require the following handling:
|
|
|
|
*
|
|
|
|
* GHES_SEV_CORRECTABLE -> AER_CORRECTABLE
|
|
|
|
* These need to be reported by the AER driver but no recovery is
|
|
|
|
* necessary.
|
|
|
|
* GHES_SEV_RECOVERABLE -> AER_NONFATAL
|
|
|
|
* GHES_SEV_RECOVERABLE && CPER_SEC_RESET -> AER_FATAL
|
|
|
|
* These both need to be reported and recovered from by the AER driver.
|
|
|
|
* GHES_SEV_PANIC does not make it to this handling since the kernel must
|
|
|
|
* panic.
|
|
|
|
*/
|
|
|
|
static void ghes_handle_aer(struct acpi_hest_generic_data *gdata)
|
2017-11-29 05:48:08 +08:00
|
|
|
{
|
|
|
|
#ifdef CONFIG_ACPI_APEI_PCIEAER
|
|
|
|
struct cper_sec_pcie *pcie_err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2017-11-29 05:48:09 +08:00
|
|
|
if (pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
|
2017-11-29 05:48:08 +08:00
|
|
|
pcie_err->validation_bits & CPER_PCIE_VALID_AER_INFO) {
|
|
|
|
unsigned int devfn;
|
|
|
|
int aer_severity;
|
|
|
|
|
|
|
|
devfn = PCI_DEVFN(pcie_err->device_id.device,
|
|
|
|
pcie_err->device_id.function);
|
|
|
|
aer_severity = cper_severity_to_aer(gdata->error_severity);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If firmware reset the component to contain
|
|
|
|
* the error, we must reinitialize it before
|
|
|
|
* use, so treat it as a fatal AER error.
|
|
|
|
*/
|
|
|
|
if (gdata->flags & CPER_SEC_RESET)
|
|
|
|
aer_severity = AER_FATAL;
|
|
|
|
|
|
|
|
aer_recover_queue(pcie_err->device_id.segment,
|
|
|
|
pcie_err->device_id.bus,
|
|
|
|
devfn, aer_severity,
|
|
|
|
(struct aer_capability_regs *)
|
|
|
|
pcie_err->aer_info);
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2013-02-15 17:10:39 +08:00
|
|
|
static void ghes_do_proc(struct ghes *ghes,
|
2014-06-03 16:32:53 +08:00
|
|
|
const struct acpi_hest_generic_status *estatus)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
2011-07-13 13:14:28 +08:00
|
|
|
int sev, sec_sev;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_data *gdata;
|
2017-06-06 00:40:43 +08:00
|
|
|
guid_t *sec_type;
|
2017-06-22 02:17:12 +08:00
|
|
|
guid_t *fru_id = &NULL_UUID_LE;
|
|
|
|
char *fru_text = "";
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
sev = ghes_severity(estatus->error_severity);
|
|
|
|
apei_estatus_for_each_section(estatus, gdata) {
|
2017-06-06 00:40:43 +08:00
|
|
|
sec_type = (guid_t *)gdata->section_type;
|
2011-07-13 13:14:28 +08:00
|
|
|
sec_sev = ghes_severity(gdata->error_severity);
|
2017-06-22 02:17:12 +08:00
|
|
|
if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
|
|
|
|
fru_id = (guid_t *)gdata->fru_id;
|
|
|
|
|
|
|
|
if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
|
|
|
|
fru_text = gdata->fru_text;
|
|
|
|
|
2017-06-06 00:40:43 +08:00
|
|
|
if (guid_equal(sec_type, &CPER_SEC_PLATFORM_MEM)) {
|
2017-06-22 02:17:05 +08:00
|
|
|
struct cper_sec_mem_err *mem_err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2018-05-01 05:33:50 +08:00
|
|
|
ghes_edac_report_mem_error(sev, mem_err);
|
2013-02-15 17:10:39 +08:00
|
|
|
|
2014-07-22 17:20:11 +08:00
|
|
|
arch_apei_report_mem_error(sev, mem_err);
|
2013-07-10 17:27:01 +08:00
|
|
|
ghes_handle_memory_failure(gdata, sev);
|
2011-07-13 13:14:28 +08:00
|
|
|
}
|
2017-06-06 00:40:43 +08:00
|
|
|
else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
|
2017-11-29 05:48:09 +08:00
|
|
|
ghes_handle_aer(gdata);
|
2011-12-08 11:25:41 +08:00
|
|
|
}
|
2017-06-22 02:17:13 +08:00
|
|
|
else if (guid_equal(sec_type, &CPER_SEC_PROC_ARM)) {
|
|
|
|
struct cper_sec_proc_arm *err = acpi_hest_get_payload(gdata);
|
|
|
|
|
|
|
|
log_arm_hw_error(err);
|
|
|
|
} else {
|
2017-06-22 02:17:12 +08:00
|
|
|
void *err = acpi_hest_get_payload(gdata);
|
|
|
|
|
|
|
|
log_non_standard_event(sec_type, fru_id, fru_text,
|
|
|
|
sec_sev, err,
|
|
|
|
gdata->error_data_length);
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
2010-12-07 10:22:31 +08:00
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
static void __ghes_print_estatus(const char *pfx,
|
|
|
|
const struct acpi_hest_generic *generic,
|
2014-06-03 16:32:53 +08:00
|
|
|
const struct acpi_hest_generic_status *estatus)
|
2010-12-07 10:22:31 +08:00
|
|
|
{
|
2011-12-08 11:25:44 +08:00
|
|
|
static atomic_t seqno;
|
|
|
|
unsigned int curr_seqno;
|
|
|
|
char pfx_seq[64];
|
|
|
|
|
2010-12-07 10:22:31 +08:00
|
|
|
if (pfx == NULL) {
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
if (ghes_severity(estatus->error_severity) <=
|
2010-12-07 10:22:31 +08:00
|
|
|
GHES_SEV_CORRECTED)
|
2011-12-08 11:25:44 +08:00
|
|
|
pfx = KERN_WARNING;
|
2010-12-07 10:22:31 +08:00
|
|
|
else
|
2011-12-08 11:25:44 +08:00
|
|
|
pfx = KERN_ERR;
|
2010-12-07 10:22:31 +08:00
|
|
|
}
|
2011-12-08 11:25:44 +08:00
|
|
|
curr_seqno = atomic_inc_return(&seqno);
|
|
|
|
snprintf(pfx_seq, sizeof(pfx_seq), "%s{%u}" HW_ERR, pfx, curr_seqno);
|
2011-07-13 13:14:15 +08:00
|
|
|
printk("%s""Hardware error from APEI Generic Hardware Error Source: %d\n",
|
2011-12-08 11:25:44 +08:00
|
|
|
pfx_seq, generic->header.source_id);
|
2013-10-19 05:28:59 +08:00
|
|
|
cper_estatus_print(pfx_seq, estatus);
|
2011-07-13 13:14:15 +08:00
|
|
|
}
|
|
|
|
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
static int ghes_print_estatus(const char *pfx,
|
|
|
|
const struct acpi_hest_generic *generic,
|
2014-06-03 16:32:53 +08:00
|
|
|
const struct acpi_hest_generic_status *estatus)
|
2011-07-13 13:14:15 +08:00
|
|
|
{
|
|
|
|
/* Not more than 2 messages every 5 seconds */
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
static DEFINE_RATELIMIT_STATE(ratelimit_corrected, 5*HZ, 2);
|
|
|
|
static DEFINE_RATELIMIT_STATE(ratelimit_uncorrected, 5*HZ, 2);
|
|
|
|
struct ratelimit_state *ratelimit;
|
2011-07-13 13:14:15 +08:00
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
if (ghes_severity(estatus->error_severity) <= GHES_SEV_CORRECTED)
|
|
|
|
ratelimit = &ratelimit_corrected;
|
|
|
|
else
|
|
|
|
ratelimit = &ratelimit_uncorrected;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
if (__ratelimit(ratelimit)) {
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
__ghes_print_estatus(pfx, generic, estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* GHES error status reporting throttle, to report more kinds of
|
|
|
|
* errors, instead of just most frequently occurred errors.
|
|
|
|
*/
|
2014-06-03 16:32:53 +08:00
|
|
|
static int ghes_estatus_cached(struct acpi_hest_generic_status *estatus)
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
{
|
|
|
|
u32 len;
|
|
|
|
int i, cached = 0;
|
|
|
|
unsigned long long now;
|
|
|
|
struct ghes_estatus_cache *cache;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *cache_estatus;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
for (i = 0; i < GHES_ESTATUS_CACHES_SIZE; i++) {
|
|
|
|
cache = rcu_dereference(ghes_estatus_caches[i]);
|
|
|
|
if (cache == NULL)
|
|
|
|
continue;
|
|
|
|
if (len != cache->estatus_len)
|
|
|
|
continue;
|
|
|
|
cache_estatus = GHES_ESTATUS_FROM_CACHE(cache);
|
|
|
|
if (memcmp(estatus, cache_estatus, len))
|
|
|
|
continue;
|
|
|
|
atomic_inc(&cache->count);
|
|
|
|
now = sched_clock();
|
|
|
|
if (now - cache->time_in < GHES_ESTATUS_IN_CACHE_MAX_NSEC)
|
|
|
|
cached = 1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
return cached;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct ghes_estatus_cache *ghes_estatus_cache_alloc(
|
|
|
|
struct acpi_hest_generic *generic,
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus)
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
{
|
|
|
|
int alloced;
|
|
|
|
u32 len, cache_len;
|
|
|
|
struct ghes_estatus_cache *cache;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *cache_estatus;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
|
|
|
|
alloced = atomic_add_return(1, &ghes_estatus_cache_alloced);
|
|
|
|
if (alloced > GHES_ESTATUS_CACHE_ALLOCED_MAX) {
|
|
|
|
atomic_dec(&ghes_estatus_cache_alloced);
|
|
|
|
return NULL;
|
|
|
|
}
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
cache_len = GHES_ESTATUS_CACHE_LEN(len);
|
|
|
|
cache = (void *)gen_pool_alloc(ghes_estatus_pool, cache_len);
|
|
|
|
if (!cache) {
|
|
|
|
atomic_dec(&ghes_estatus_cache_alloced);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
cache_estatus = GHES_ESTATUS_FROM_CACHE(cache);
|
|
|
|
memcpy(cache_estatus, estatus, len);
|
|
|
|
cache->estatus_len = len;
|
|
|
|
atomic_set(&cache->count, 0);
|
|
|
|
cache->generic = generic;
|
|
|
|
cache->time_in = sched_clock();
|
|
|
|
return cache;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_estatus_cache_free(struct ghes_estatus_cache *cache)
|
|
|
|
{
|
|
|
|
u32 len;
|
|
|
|
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(GHES_ESTATUS_FROM_CACHE(cache));
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
len = GHES_ESTATUS_CACHE_LEN(len);
|
|
|
|
gen_pool_free(ghes_estatus_pool, (unsigned long)cache, len);
|
|
|
|
atomic_dec(&ghes_estatus_cache_alloced);
|
|
|
|
}
|
|
|
|
|
|
|
|
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 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus)
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
{
|
|
|
|
int 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-03 06:00:21 +08:00
|
|
|
period = duration;
|
|
|
|
do_div(period, (count + 1));
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
if (period > max_period) {
|
|
|
|
max_period = period;
|
|
|
|
slot = i;
|
|
|
|
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 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
static void __ghes_panic(struct ghes *ghes,
|
|
|
|
struct acpi_hest_generic_status *estatus,
|
|
|
|
u64 buf_paddr, enum fixed_addresses fixmap_idx)
|
2017-06-22 02:17:10 +08:00
|
|
|
{
|
2019-01-30 02:48:53 +08:00
|
|
|
__ghes_print_estatus(KERN_EMERG, ghes->generic, estatus);
|
2017-06-22 02:17:10 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);
|
2018-12-20 00:50:52 +08:00
|
|
|
|
2017-06-22 02:17:10 +08:00
|
|
|
/* reboot to log the error! */
|
|
|
|
if (!panic_timeout)
|
|
|
|
panic_timeout = ghes_panic_timeout;
|
|
|
|
panic("Fatal hardware error!");
|
|
|
|
}
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
static int ghes_proc(struct ghes *ghes)
|
|
|
|
{
|
2019-01-30 02:48:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus = ghes->estatus;
|
2019-01-30 02:48:42 +08:00
|
|
|
u64 buf_paddr;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
int rc;
|
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
rc = ghes_read_estatus(ghes, estatus, &buf_paddr, FIX_APEI_GHES_IRQ);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (rc)
|
|
|
|
goto out;
|
2017-06-22 02:17:10 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
if (ghes_severity(estatus->error_severity) >= GHES_SEV_PANIC)
|
|
|
|
__ghes_panic(ghes, estatus, buf_paddr, FIX_APEI_GHES_IRQ);
|
2017-06-22 02:17:10 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
if (!ghes_estatus_cached(estatus)) {
|
|
|
|
if (ghes_print_estatus(NULL, ghes->generic, estatus))
|
|
|
|
ghes_estatus_cache_add(ghes->generic, estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
}
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_do_proc(ghes, estatus);
|
2017-06-22 02:17:04 +08:00
|
|
|
|
2017-08-29 00:53:41 +08:00
|
|
|
out:
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, FIX_APEI_GHES_IRQ);
|
2017-08-29 00:53:41 +08:00
|
|
|
|
2016-10-19 00:07:19 +08:00
|
|
|
return rc;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
static void ghes_add_timer(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
struct acpi_hest_generic *g = ghes->generic;
|
|
|
|
unsigned long expire;
|
|
|
|
|
|
|
|
if (!g->notify.poll_interval) {
|
|
|
|
pr_warning(FW_WARN GHES_PFX "Poll interval is 0 for generic hardware error source: %d, disabled.\n",
|
|
|
|
g->header.source_id);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
expire = jiffies + msecs_to_jiffies(g->notify.poll_interval);
|
|
|
|
ghes->timer.expires = round_jiffies_relative(expire);
|
|
|
|
add_timer(&ghes->timer);
|
|
|
|
}
|
|
|
|
|
2017-10-13 07:19:27 +08:00
|
|
|
static void ghes_poll_func(struct timer_list *t)
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
{
|
2017-10-13 07:19:27 +08:00
|
|
|
struct ghes *ghes = from_timer(ghes, t, timer);
|
2019-01-30 02:48:51 +08:00
|
|
|
unsigned long flags;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
ghes_proc(ghes);
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
if (!(ghes->flags & GHES_EXITING))
|
|
|
|
ghes_add_timer(ghes);
|
|
|
|
}
|
|
|
|
|
|
|
|
static irqreturn_t ghes_irq_func(int irq, void *data)
|
|
|
|
{
|
|
|
|
struct ghes *ghes = data;
|
2019-01-30 02:48:51 +08:00
|
|
|
unsigned long flags;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
int rc;
|
|
|
|
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
rc = ghes_proc(ghes);
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
if (rc)
|
|
|
|
return IRQ_NONE;
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
2017-05-19 17:39:11 +08:00
|
|
|
static int ghes_notify_hed(struct notifier_block *this, unsigned long event,
|
|
|
|
void *data)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
|
|
|
struct ghes *ghes;
|
2019-01-30 02:48:51 +08:00
|
|
|
unsigned long flags;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
int ret = NOTIFY_DONE;
|
|
|
|
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
rcu_read_lock();
|
2017-05-19 17:39:11 +08:00
|
|
|
list_for_each_entry_rcu(ghes, &ghes_hed, list) {
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (!ghes_proc(ghes))
|
|
|
|
ret = NOTIFY_OK;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-05-19 17:39:11 +08:00
|
|
|
static struct notifier_block ghes_notifier_hed = {
|
|
|
|
.notifier_call = ghes_notify_hed,
|
2014-07-22 17:20:12 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
2019-01-30 02:48:47 +08:00
|
|
|
* Handlers for CPER records may not be NMI safe. For example,
|
|
|
|
* memory_failure_queue() takes spinlocks and calls schedule_work_on().
|
|
|
|
* In any NMI-like handler, memory from ghes_estatus_pool is used to save
|
|
|
|
* estatus, and added to the ghes_estatus_llist. irq_work_queue() causes
|
|
|
|
* ghes_proc_in_irq() to run in IRQ context where each estatus in
|
|
|
|
* ghes_estatus_llist is processed.
|
|
|
|
*
|
|
|
|
* Memory from the ghes_estatus_pool is also used with the ghes_estatus_cache
|
|
|
|
* to suppress frequent messages.
|
2014-07-22 17:20:12 +08:00
|
|
|
*/
|
|
|
|
static struct llist_head ghes_estatus_llist;
|
|
|
|
static struct irq_work ghes_proc_irq_work;
|
|
|
|
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
static void ghes_proc_in_irq(struct irq_work *irq_work)
|
|
|
|
{
|
2011-12-08 11:25:45 +08:00
|
|
|
struct llist_node *llnode, *next;
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
struct ghes_estatus_node *estatus_node;
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
struct acpi_hest_generic *generic;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus;
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
u32 len, node_len;
|
|
|
|
|
2011-12-08 11:25:45 +08:00
|
|
|
llnode = llist_del_all(&ghes_estatus_llist);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
/*
|
|
|
|
* Because the time order of estatus in list is reversed,
|
|
|
|
* revert it back to proper order.
|
|
|
|
*/
|
2014-07-28 14:50:59 +08:00
|
|
|
llnode = llist_reverse_order(llnode);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
while (llnode) {
|
|
|
|
next = llnode->next;
|
|
|
|
estatus_node = llist_entry(llnode, struct ghes_estatus_node,
|
|
|
|
llnode);
|
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(estatus);
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(len);
|
2013-02-15 17:10:39 +08:00
|
|
|
ghes_do_proc(estatus_node->ghes, estatus);
|
ACPI, APEI, GHES, Error records content based throttle
printk is used by GHES to report hardware errors. Ratelimit is
enforced on the printk to avoid too many hardware error reports in
kernel log. Because there may be thousands or even millions of
corrected hardware errors during system running.
Currently, a simple scheme is used. That is, the total number of
hardware error reporting is ratelimited. This may cause some issues
in practice.
For example, there are two kinds of hardware errors occurred in
system. One is corrected memory error, because the fault memory
address is accessed frequently, there may be hundreds error report
per-second. The other is corrected PCIe AER error, it will be
reported once per-second. Because they share one ratelimit control
structure, it is highly possible that only memory error is reported.
To avoid the above issue, an error record content based throttle
algorithm is implemented in the patch. Where after the first
successful reporting, all error records that are same are throttled for
some time, to let other kinds of error records have the opportunity to
be reported.
In above example, the memory errors will be throttled for some time,
after being printked. Then the PCIe AER error will be printked
successfully.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:26 +08:00
|
|
|
if (!ghes_estatus_cached(estatus)) {
|
|
|
|
generic = estatus_node->generic;
|
|
|
|
if (ghes_print_estatus(NULL, generic, estatus))
|
|
|
|
ghes_estatus_cache_add(generic, estatus);
|
|
|
|
}
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
|
|
|
|
node_len);
|
|
|
|
llnode = next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2011-12-08 11:25:45 +08:00
|
|
|
static void ghes_print_queued_estatus(void)
|
|
|
|
{
|
|
|
|
struct llist_node *llnode;
|
|
|
|
struct ghes_estatus_node *estatus_node;
|
|
|
|
struct acpi_hest_generic *generic;
|
2014-06-03 16:32:53 +08:00
|
|
|
struct acpi_hest_generic_status *estatus;
|
2011-12-08 11:25:45 +08:00
|
|
|
|
|
|
|
llnode = llist_del_all(&ghes_estatus_llist);
|
|
|
|
/*
|
|
|
|
* Because the time order of estatus in list is reversed,
|
|
|
|
* revert it back to proper order.
|
|
|
|
*/
|
2014-07-28 14:50:59 +08:00
|
|
|
llnode = llist_reverse_order(llnode);
|
2011-12-08 11:25:45 +08:00
|
|
|
while (llnode) {
|
|
|
|
estatus_node = llist_entry(llnode, struct ghes_estatus_node,
|
|
|
|
llnode);
|
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
|
|
|
generic = estatus_node->generic;
|
|
|
|
ghes_print_estatus(NULL, generic, estatus);
|
|
|
|
llnode = llnode->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
static int ghes_in_nmi_queue_one_entry(struct ghes *ghes,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
2015-03-18 16:41:35 +08:00
|
|
|
{
|
2019-01-30 02:48:56 +08:00
|
|
|
struct acpi_hest_generic_status *estatus, tmp_header;
|
2015-03-18 16:41:35 +08:00
|
|
|
struct ghes_estatus_node *estatus_node;
|
2019-01-30 02:48:56 +08:00
|
|
|
u32 len, node_len;
|
|
|
|
u64 buf_paddr;
|
|
|
|
int sev, rc;
|
2015-03-18 16:41:35 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG))
|
2019-01-30 02:48:56 +08:00
|
|
|
return -EOPNOTSUPP;
|
2015-03-18 16:41:35 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
rc = __ghes_peek_estatus(ghes, &tmp_header, &buf_paddr, fixmap_idx);
|
|
|
|
if (rc) {
|
|
|
|
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
|
|
|
|
return rc;
|
|
|
|
}
|
2019-01-30 02:48:53 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
rc = __ghes_check_estatus(ghes, &tmp_header);
|
|
|
|
if (rc) {
|
|
|
|
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
|
|
|
|
return rc;
|
|
|
|
}
|
2015-03-18 16:41:35 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
len = cper_estatus_len(&tmp_header);
|
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(len);
|
2015-03-18 16:41:35 +08:00
|
|
|
estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
|
|
|
|
if (!estatus_node)
|
2019-01-30 02:48:56 +08:00
|
|
|
return -ENOMEM;
|
2015-03-18 16:41:35 +08:00
|
|
|
|
|
|
|
estatus_node->ghes = ghes;
|
|
|
|
estatus_node->generic = ghes->generic;
|
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
if (__ghes_read_estatus(estatus, buf_paddr, fixmap_idx, len)) {
|
2019-01-30 02:48:53 +08:00
|
|
|
ghes_clear_estatus(ghes, estatus, buf_paddr, fixmap_idx);
|
2019-01-30 02:48:56 +08:00
|
|
|
rc = -ENOENT;
|
|
|
|
goto no_work;
|
2019-01-30 02:48:45 +08:00
|
|
|
}
|
2015-03-27 17:05:00 +08:00
|
|
|
|
2019-01-30 02:48:53 +08:00
|
|
|
sev = ghes_severity(estatus->error_severity);
|
2019-01-30 02:48:45 +08:00
|
|
|
if (sev >= GHES_SEV_PANIC) {
|
|
|
|
ghes_print_queued_estatus();
|
2019-01-30 02:48:53 +08:00
|
|
|
__ghes_panic(ghes, estatus, buf_paddr, fixmap_idx);
|
2019-01-30 02:48:45 +08:00
|
|
|
}
|
2015-03-18 16:55:21 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
ghes_clear_estatus(ghes, &tmp_header, buf_paddr, fixmap_idx);
|
2015-03-18 16:55:21 +08:00
|
|
|
|
2019-01-30 02:48:56 +08:00
|
|
|
/* This error has been reported before, don't process it again. */
|
|
|
|
if (ghes_estatus_cached(estatus))
|
|
|
|
goto no_work;
|
|
|
|
|
|
|
|
llist_add(&estatus_node->llnode, &ghes_estatus_llist);
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
|
|
|
|
no_work:
|
|
|
|
gen_pool_free(ghes_estatus_pool, (unsigned long)estatus_node,
|
|
|
|
node_len);
|
|
|
|
|
|
|
|
return rc;
|
2019-01-30 02:48:45 +08:00
|
|
|
}
|
|
|
|
|
2019-01-30 02:48:52 +08:00
|
|
|
static int ghes_in_nmi_spool_from_list(struct list_head *rcu_list,
|
|
|
|
enum fixed_addresses fixmap_idx)
|
2019-01-30 02:48:45 +08:00
|
|
|
{
|
|
|
|
int ret = -ENOENT;
|
|
|
|
struct ghes *ghes;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(ghes, rcu_list, list) {
|
2019-01-30 02:48:52 +08:00
|
|
|
if (!ghes_in_nmi_queue_one_entry(ghes, fixmap_idx))
|
2019-01-30 02:48:45 +08:00
|
|
|
ret = 0;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
2019-01-30 02:48:45 +08:00
|
|
|
rcu_read_unlock();
|
2015-03-18 16:41:35 +08:00
|
|
|
|
2019-01-30 02:48:45 +08:00
|
|
|
if (IS_ENABLED(CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG) && !ret)
|
2016-11-30 21:19:39 +08:00
|
|
|
irq_work_queue(&ghes_proc_irq_work);
|
2019-01-30 02:48:45 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2019-01-30 02:48:47 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_ACPI_APEI_SEA
|
|
|
|
static LIST_HEAD(ghes_sea);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return 0 only if one of the SEA error sources successfully reported an error
|
|
|
|
* record sent from the firmware.
|
|
|
|
*/
|
|
|
|
int ghes_notify_sea(void)
|
|
|
|
{
|
2019-01-30 02:48:51 +08:00
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_notify_lock_sea);
|
|
|
|
int rv;
|
|
|
|
|
|
|
|
raw_spin_lock(&ghes_notify_lock_sea);
|
2019-01-30 02:48:57 +08:00
|
|
|
rv = ghes_in_nmi_spool_from_list(&ghes_sea, FIX_APEI_GHES_SEA);
|
2019-01-30 02:48:51 +08:00
|
|
|
raw_spin_unlock(&ghes_notify_lock_sea);
|
|
|
|
|
|
|
|
return rv;
|
2019-01-30 02:48:47 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_sea_add(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_add_rcu(&ghes->list, &ghes_sea);
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_sea_remove(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_del_rcu(&ghes->list);
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
|
|
|
synchronize_rcu();
|
|
|
|
}
|
|
|
|
#else /* CONFIG_ACPI_APEI_SEA */
|
|
|
|
static inline void ghes_sea_add(struct ghes *ghes) { }
|
|
|
|
static inline void ghes_sea_remove(struct ghes *ghes) { }
|
|
|
|
#endif /* CONFIG_ACPI_APEI_SEA */
|
|
|
|
|
|
|
|
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
|
|
|
|
/*
|
|
|
|
* NMI may be triggered on any CPU, so ghes_in_nmi is used for
|
|
|
|
* having only one concurrent reader.
|
|
|
|
*/
|
|
|
|
static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
|
|
|
|
|
|
|
|
static LIST_HEAD(ghes_nmi);
|
2019-01-30 02:48:45 +08:00
|
|
|
|
|
|
|
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
|
|
|
|
{
|
2019-01-30 02:48:51 +08:00
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_notify_lock_nmi);
|
2019-01-30 02:48:45 +08:00
|
|
|
int ret = NMI_DONE;
|
|
|
|
|
|
|
|
if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
|
|
|
|
return ret;
|
|
|
|
|
2019-01-30 02:48:51 +08:00
|
|
|
raw_spin_lock(&ghes_notify_lock_nmi);
|
2019-01-30 02:48:52 +08:00
|
|
|
if (!ghes_in_nmi_spool_from_list(&ghes_nmi, FIX_APEI_GHES_NMI))
|
2019-01-30 02:48:45 +08:00
|
|
|
ret = NMI_HANDLED;
|
2019-01-30 02:48:51 +08:00
|
|
|
raw_spin_unlock(&ghes_notify_lock_nmi);
|
2019-01-30 02:48:45 +08:00
|
|
|
|
2015-03-27 17:05:00 +08:00
|
|
|
atomic_dec(&ghes_in_nmi);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-07-22 17:20:12 +08:00
|
|
|
static void ghes_nmi_add(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
if (list_empty(&ghes_nmi))
|
|
|
|
register_nmi_handler(NMI_LOCAL, ghes_notify_nmi, 0, "ghes");
|
|
|
|
list_add_rcu(&ghes->list, &ghes_nmi);
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_nmi_remove(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_del_rcu(&ghes->list);
|
|
|
|
if (list_empty(&ghes_nmi))
|
|
|
|
unregister_nmi_handler(NMI_LOCAL, "ghes");
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
|
|
|
/*
|
|
|
|
* To synchronize with NMI handler, ghes can only be
|
|
|
|
* freed after NMI handler finishes.
|
|
|
|
*/
|
|
|
|
synchronize_rcu();
|
|
|
|
}
|
2019-01-30 02:48:48 +08:00
|
|
|
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
|
|
|
|
static inline void ghes_nmi_add(struct ghes *ghes) { }
|
|
|
|
static inline void ghes_nmi_remove(struct ghes *ghes) { }
|
|
|
|
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
|
2014-07-22 17:20:12 +08:00
|
|
|
|
|
|
|
static void ghes_nmi_init_cxt(void)
|
|
|
|
{
|
|
|
|
init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
|
|
|
|
}
|
|
|
|
|
2012-11-20 02:22:46 +08:00
|
|
|
static int ghes_probe(struct platform_device *ghes_dev)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
|
|
|
struct acpi_hest_generic *generic;
|
|
|
|
struct ghes *ghes = NULL;
|
2019-01-30 02:48:51 +08:00
|
|
|
unsigned long flags;
|
2014-07-22 17:20:12 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
int rc = -EINVAL;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2010-09-29 19:53:53 +08:00
|
|
|
generic = *(struct acpi_hest_generic **)ghes_dev->dev.platform_data;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (!generic->enabled)
|
2010-08-02 15:48:24 +08:00
|
|
|
return -ENODEV;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
switch (generic->notify.type) {
|
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 17:39:11 +08:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2014-07-22 17:20:12 +08:00
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
2017-06-22 02:17:09 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SEA:
|
|
|
|
if (!IS_ENABLED(CONFIG_ACPI_APEI_SEA)) {
|
|
|
|
pr_warn(GHES_PFX "Generic hardware error source: %d notified via SEA is not supported\n",
|
|
|
|
generic->header.source_id);
|
|
|
|
rc = -ENOTSUPP;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 17:20:12 +08:00
|
|
|
if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_NMI)) {
|
|
|
|
pr_warn(GHES_PFX "Generic hardware error source: %d notified via NMI interrupt is not supported!\n",
|
|
|
|
generic->header.source_id);
|
|
|
|
goto err;
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
|
|
|
case ACPI_HEST_NOTIFY_LOCAL:
|
|
|
|
pr_warning(GHES_PFX "Generic hardware error source: %d notified via local interrupt is not supported!\n",
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
generic->header.source_id);
|
|
|
|
goto err;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
default:
|
|
|
|
pr_warning(FW_WARN GHES_PFX "Unknown notification type: %u for generic hardware error source: %d\n",
|
|
|
|
generic->notify.type, generic->header.source_id);
|
|
|
|
goto err;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
|
|
|
|
rc = -EIO;
|
|
|
|
if (generic->error_block_length <
|
2014-06-03 16:32:53 +08:00
|
|
|
sizeof(struct acpi_hest_generic_status)) {
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
pr_warning(FW_BUG GHES_PFX "Invalid error block length: %u for generic hardware error source: %d\n",
|
|
|
|
generic->error_block_length,
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
generic->header.source_id);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
ghes = ghes_new(generic);
|
|
|
|
if (IS_ERR(ghes)) {
|
|
|
|
rc = PTR_ERR(ghes);
|
|
|
|
ghes = NULL;
|
|
|
|
goto err;
|
|
|
|
}
|
2013-02-15 17:10:39 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
switch (generic->notify.type) {
|
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
2017-10-13 07:19:27 +08:00
|
|
|
timer_setup(&ghes->timer, ghes_poll_func, TIMER_DEFERRABLE);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
ghes_add_timer(ghes);
|
|
|
|
break;
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
/* External interrupt vector is GSI */
|
2013-06-03 10:08:39 +08:00
|
|
|
rc = acpi_gsi_to_irq(generic->notify.vector, &ghes->irq);
|
|
|
|
if (rc) {
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
pr_err(GHES_PFX "Failed to map GSI to IRQ for generic hardware error source: %d\n",
|
|
|
|
generic->header.source_id);
|
2018-04-23 20:16:46 +08:00
|
|
|
goto err;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
2017-07-22 02:24:37 +08:00
|
|
|
rc = request_irq(ghes->irq, ghes_irq_func, IRQF_SHARED,
|
|
|
|
"GHES IRQ", ghes);
|
2013-06-03 10:08:39 +08:00
|
|
|
if (rc) {
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
pr_err(GHES_PFX "Failed to register IRQ for generic hardware error source: %d\n",
|
|
|
|
generic->header.source_id);
|
2018-04-23 20:16:46 +08:00
|
|
|
goto err;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
}
|
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 17:39:11 +08:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_lock(&ghes_list_mutex);
|
2017-05-19 17:39:11 +08:00
|
|
|
if (list_empty(&ghes_hed))
|
|
|
|
register_acpi_hed_notifier(&ghes_notifier_hed);
|
|
|
|
list_add_rcu(&ghes->list, &ghes_hed);
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_unlock(&ghes_list_mutex);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
2017-06-22 02:17:09 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SEA:
|
|
|
|
ghes_sea_add(ghes);
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 17:20:12 +08:00
|
|
|
ghes_nmi_add(ghes);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
BUG();
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
2018-04-23 20:16:46 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
platform_set_drvdata(ghes_dev, ghes);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2018-04-23 20:16:46 +08:00
|
|
|
ghes_edac_register(ghes, &ghes_dev->dev);
|
|
|
|
|
2017-06-22 02:17:15 +08:00
|
|
|
/* Handle any pending errors right away */
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_lock_irqsave(&ghes_notify_lock_irq, flags);
|
2017-06-22 02:17:15 +08:00
|
|
|
ghes_proc(ghes);
|
2019-01-30 02:48:51 +08:00
|
|
|
spin_unlock_irqrestore(&ghes_notify_lock_irq, flags);
|
2017-06-22 02:17:15 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
return 0;
|
2018-04-23 20:16:46 +08:00
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
err:
|
2010-08-02 15:48:24 +08:00
|
|
|
if (ghes) {
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
ghes_fini(ghes);
|
2010-08-02 15:48:24 +08:00
|
|
|
kfree(ghes);
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
2012-11-22 06:13:09 +08:00
|
|
|
static int ghes_remove(struct platform_device *ghes_dev)
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
{
|
2010-08-02 15:48:24 +08:00
|
|
|
struct ghes *ghes;
|
|
|
|
struct acpi_hest_generic *generic;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
ghes = platform_get_drvdata(ghes_dev);
|
|
|
|
generic = ghes->generic;
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
ghes->flags |= GHES_EXITING;
|
2010-08-02 15:48:24 +08:00
|
|
|
switch (generic->notify.type) {
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
|
|
|
del_timer_sync(&ghes->timer);
|
|
|
|
break;
|
|
|
|
case ACPI_HEST_NOTIFY_EXTERNAL:
|
|
|
|
free_irq(ghes->irq, ghes);
|
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
2017-05-19 17:39:11 +08:00
|
|
|
case ACPI_HEST_NOTIFY_GSIV:
|
|
|
|
case ACPI_HEST_NOTIFY_GPIO:
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_del_rcu(&ghes->list);
|
2017-05-19 17:39:11 +08:00
|
|
|
if (list_empty(&ghes_hed))
|
|
|
|
unregister_acpi_hed_notifier(&ghes_notifier_hed);
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_unlock(&ghes_list_mutex);
|
2017-03-16 22:30:39 +08:00
|
|
|
synchronize_rcu();
|
2010-08-02 15:48:24 +08:00
|
|
|
break;
|
2017-05-19 17:39:11 +08:00
|
|
|
|
2017-06-22 02:17:09 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SEA:
|
|
|
|
ghes_sea_remove(ghes);
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
case ACPI_HEST_NOTIFY_NMI:
|
2014-07-22 17:20:12 +08:00
|
|
|
ghes_nmi_remove(ghes);
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
break;
|
2010-08-02 15:48:24 +08:00
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
break;
|
|
|
|
}
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
ghes_fini(ghes);
|
2013-02-15 17:10:39 +08:00
|
|
|
|
|
|
|
ghes_edac_unregister(ghes);
|
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
kfree(ghes);
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
|
2010-08-02 15:48:24 +08: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 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2010-08-02 15:48:24 +08:00
|
|
|
static struct platform_driver ghes_platform_driver = {
|
|
|
|
.driver = {
|
|
|
|
.name = "GHES",
|
|
|
|
},
|
|
|
|
.probe = ghes_probe,
|
|
|
|
.remove = ghes_remove,
|
|
|
|
};
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
static int __init ghes_init(void)
|
|
|
|
{
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
int rc;
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
if (acpi_disabled)
|
|
|
|
return -ENODEV;
|
|
|
|
|
2017-08-29 21:20:20 +08:00
|
|
|
switch (hest_disable) {
|
|
|
|
case HEST_NOT_FOUND:
|
|
|
|
return -ENODEV;
|
|
|
|
case HEST_DISABLED:
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
pr_info(GHES_PFX "HEST is not enabled!\n");
|
|
|
|
return -EINVAL;
|
2017-08-29 21:20:20 +08:00
|
|
|
default:
|
|
|
|
break;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
|
|
|
|
2011-07-13 13:14:19 +08:00
|
|
|
if (ghes_disable) {
|
|
|
|
pr_info(GHES_PFX "GHES is not enabled!\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2014-07-22 17:20:12 +08:00
|
|
|
ghes_nmi_init_cxt();
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
|
|
|
|
rc = platform_driver_register(&ghes_platform_driver);
|
|
|
|
if (rc)
|
2019-01-30 02:48:40 +08:00
|
|
|
goto err;
|
ACPI, APEI, GHES, printk support for recoverable error via NMI
Some APEI GHES recoverable errors are reported via NMI, but printk is
not safe in NMI context.
To solve the issue, a lock-less memory allocator is used to allocate
memory in NMI handler, save the error record into the allocated
memory, put the error record into a lock-less list. On the other
hand, an irq_work is used to delay the operation from NMI context to
IRQ context. The irq_work IRQ handler will remove nodes from
lock-less list, printk the error record and do some further processing
include recovery operation, then free the memory.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-07-13 13:14:25 +08:00
|
|
|
|
2011-07-13 13:14:21 +08:00
|
|
|
rc = apei_osc_setup();
|
|
|
|
if (rc == 0 && osc_sb_apei_support_acked)
|
|
|
|
pr_info(GHES_PFX "APEI firmware first mode is enabled by APEI bit and WHEA _OSC.\n");
|
|
|
|
else if (rc == 0 && !osc_sb_apei_support_acked)
|
|
|
|
pr_info(GHES_PFX "APEI firmware first mode is enabled by WHEA _OSC.\n");
|
|
|
|
else if (rc && osc_sb_apei_support_acked)
|
|
|
|
pr_info(GHES_PFX "APEI firmware first mode is enabled by APEI bit.\n");
|
|
|
|
else
|
|
|
|
pr_info(GHES_PFX "Failed to enable APEI firmware first mode.\n");
|
|
|
|
|
ACPI, APEI, Generic Hardware Error Source POLL/IRQ/NMI notification type support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
This patch adds POLL/IRQ/NMI notification types support.
Because the memory area used to transfer hardware error information
from BIOS to Linux can be determined only in NMI, IRQ or timer
handler, but general ioremap can not be used in atomic context, so a
special version of atomic ioremap is implemented for that.
Known issue:
- Error information can not be printed for recoverable errors notified
via NMI, because printk is not NMI-safe. Will fix this via delay
printing to IRQ context via irq_work or make printk NMI-safe.
v2:
- adjust printk format per comments.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Reviewed-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-01-12 14:44:55 +08:00
|
|
|
return 0;
|
|
|
|
err:
|
|
|
|
return rc;
|
ACPI, APEI, Generic Hardware Error Source memory error support
Generic Hardware Error Source provides a way to report platform
hardware errors (such as that from chipset). It works in so called
"Firmware First" mode, that is, hardware errors are reported to
firmware firstly, then reported to Linux by firmware. This way, some
non-standard hardware error registers or non-standard hardware link
can be checked by firmware to produce more valuable hardware error
information for Linux.
Now, only SCI notification type and memory errors are supported. More
notification type and hardware error type will be added later. These
memory errors are reported to user space through /dev/mcelog via
faking a corrected Machine Check, so that the error memory page can be
offlined by /sbin/mcelog if the error count for one page is beyond the
threshold.
On some machines, Machine Check can not report physical address for
some corrected memory errors, but GHES can do that. So this simplified
GHES is implemented firstly.
Signed-off-by: Huang Ying <ying.huang@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2010-05-18 14:35:20 +08:00
|
|
|
}
|
2016-02-15 13:27:50 +08:00
|
|
|
device_initcall(ghes_init);
|