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>
|
|
|
|
#include <linux/kdebug.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>
|
|
|
|
#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>
|
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>
|
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>
|
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
|
|
|
/*
|
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
|
|
|
* All error sources notified with SCI shares one notifier function,
|
|
|
|
* so they need to be linked and checked one by one. This is applied
|
|
|
|
* to 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
|
|
|
*/
|
|
|
|
static LIST_HEAD(ghes_sci);
|
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
|
|
|
|
* a special version of atomic ioremap is implemented for that.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
2014-07-22 17:20:13 +08:00
|
|
|
* Two virtual pages are used, one for IRQ/PROCESS context, the other for
|
|
|
|
* NMI context (optionally).
|
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
|
|
|
*/
|
2014-07-22 17:20:13 +08:00
|
|
|
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
|
|
|
|
#define GHES_IOREMAP_PAGES 2
|
|
|
|
#else
|
|
|
|
#define GHES_IOREMAP_PAGES 1
|
|
|
|
#endif
|
|
|
|
#define GHES_IOREMAP_IRQ_PAGE(base) (base)
|
|
|
|
#define GHES_IOREMAP_NMI_PAGE(base) ((base) + PAGE_SIZE)
|
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
|
|
|
|
|
|
|
/* virtual memory area for atomic ioremap */
|
|
|
|
static struct vm_struct *ghes_ioremap_area;
|
|
|
|
/*
|
|
|
|
* These 2 spinlock is used to prevent atomic ioremap virtual memory
|
|
|
|
* area from being mapped simultaneously.
|
|
|
|
*/
|
|
|
|
static DEFINE_RAW_SPINLOCK(ghes_ioremap_lock_nmi);
|
|
|
|
static DEFINE_SPINLOCK(ghes_ioremap_lock_irq);
|
|
|
|
|
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;
|
|
|
|
|
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 int ghes_ioremap_init(void)
|
|
|
|
{
|
|
|
|
ghes_ioremap_area = __get_vm_area(PAGE_SIZE * GHES_IOREMAP_PAGES,
|
|
|
|
VM_IOREMAP, VMALLOC_START, VMALLOC_END);
|
|
|
|
if (!ghes_ioremap_area) {
|
|
|
|
pr_err(GHES_PFX "Failed to allocate virtual memory area for atomic ioremap.\n");
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_ioremap_exit(void)
|
|
|
|
{
|
|
|
|
free_vm_area(ghes_ioremap_area);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __iomem *ghes_ioremap_pfn_nmi(u64 pfn)
|
|
|
|
{
|
|
|
|
unsigned long vaddr;
|
|
|
|
|
|
|
|
vaddr = (unsigned long)GHES_IOREMAP_NMI_PAGE(ghes_ioremap_area->addr);
|
|
|
|
ioremap_page_range(vaddr, vaddr + PAGE_SIZE,
|
|
|
|
pfn << PAGE_SHIFT, PAGE_KERNEL);
|
|
|
|
|
|
|
|
return (void __iomem *)vaddr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __iomem *ghes_ioremap_pfn_irq(u64 pfn)
|
|
|
|
{
|
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
|
|
|
unsigned long vaddr, 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
|
|
|
|
|
|
|
vaddr = (unsigned long)GHES_IOREMAP_IRQ_PAGE(ghes_ioremap_area->addr);
|
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
|
|
|
|
|
|
|
paddr = pfn << PAGE_SHIFT;
|
|
|
|
prot = arch_apei_get_mem_attribute(paddr);
|
|
|
|
|
|
|
|
ioremap_page_range(vaddr, vaddr + PAGE_SIZE, 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
|
|
|
|
|
|
|
return (void __iomem *)vaddr;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_iounmap_nmi(void __iomem *vaddr_ptr)
|
|
|
|
{
|
|
|
|
unsigned long vaddr = (unsigned long __force)vaddr_ptr;
|
|
|
|
void *base = ghes_ioremap_area->addr;
|
|
|
|
|
|
|
|
BUG_ON(vaddr != (unsigned long)GHES_IOREMAP_NMI_PAGE(base));
|
|
|
|
unmap_kernel_range_noflush(vaddr, PAGE_SIZE);
|
2014-07-22 17:20:13 +08:00
|
|
|
arch_apei_flush_tlb_one(vaddr);
|
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_iounmap_irq(void __iomem *vaddr_ptr)
|
|
|
|
{
|
|
|
|
unsigned long vaddr = (unsigned long __force)vaddr_ptr;
|
|
|
|
void *base = ghes_ioremap_area->addr;
|
|
|
|
|
|
|
|
BUG_ON(vaddr != (unsigned long)GHES_IOREMAP_IRQ_PAGE(base));
|
|
|
|
unmap_kernel_range_noflush(vaddr, PAGE_SIZE);
|
2014-07-22 17:20:13 +08:00
|
|
|
arch_apei_flush_tlb_one(vaddr);
|
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 int ghes_estatus_pool_init(void)
|
|
|
|
{
|
|
|
|
ghes_estatus_pool = gen_pool_create(GHES_ESTATUS_POOL_MIN_ALLOC_ORDER, -1);
|
|
|
|
if (!ghes_estatus_pool)
|
|
|
|
return -ENOMEM;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_estatus_pool_free_chunk_page(struct gen_pool *pool,
|
|
|
|
struct gen_pool_chunk *chunk,
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
free_page(chunk->start_addr);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_estatus_pool_exit(void)
|
|
|
|
{
|
|
|
|
gen_pool_for_each_chunk(ghes_estatus_pool,
|
|
|
|
ghes_estatus_pool_free_chunk_page, NULL);
|
|
|
|
gen_pool_destroy(ghes_estatus_pool);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ghes_estatus_pool_expand(unsigned long len)
|
|
|
|
{
|
|
|
|
unsigned long i, pages, size, addr;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ghes_estatus_pool_size_request += PAGE_ALIGN(len);
|
|
|
|
size = gen_pool_size(ghes_estatus_pool);
|
|
|
|
if (size >= ghes_estatus_pool_size_request)
|
|
|
|
return 0;
|
|
|
|
pages = (ghes_estatus_pool_size_request - size) / PAGE_SIZE;
|
|
|
|
for (i = 0; i < pages; i++) {
|
|
|
|
addr = __get_free_page(GFP_KERNEL);
|
|
|
|
if (!addr)
|
|
|
|
return -ENOMEM;
|
|
|
|
ret = gen_pool_add(ghes_estatus_pool, addr, PAGE_SIZE, -1);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
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,
|
|
|
|
int from_phys)
|
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;
|
|
|
|
unsigned long flags = 0;
|
|
|
|
int in_nmi = in_nmi();
|
|
|
|
u64 offset;
|
|
|
|
u32 trunk;
|
|
|
|
|
|
|
|
while (len > 0) {
|
|
|
|
offset = paddr - (paddr & PAGE_MASK);
|
|
|
|
if (in_nmi) {
|
|
|
|
raw_spin_lock(&ghes_ioremap_lock_nmi);
|
|
|
|
vaddr = ghes_ioremap_pfn_nmi(paddr >> PAGE_SHIFT);
|
|
|
|
} else {
|
|
|
|
spin_lock_irqsave(&ghes_ioremap_lock_irq, flags);
|
|
|
|
vaddr = ghes_ioremap_pfn_irq(paddr >> PAGE_SHIFT);
|
|
|
|
}
|
|
|
|
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;
|
|
|
|
if (in_nmi) {
|
|
|
|
ghes_iounmap_nmi(vaddr);
|
|
|
|
raw_spin_unlock(&ghes_ioremap_lock_nmi);
|
|
|
|
} else {
|
|
|
|
ghes_iounmap_irq(vaddr);
|
|
|
|
spin_unlock_irqrestore(&ghes_ioremap_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
|
|
|
}
|
|
|
|
|
|
|
|
static int ghes_read_estatus(struct ghes *ghes, int silent)
|
|
|
|
{
|
|
|
|
struct acpi_hest_generic *g = ghes->generic;
|
|
|
|
u64 buf_paddr;
|
|
|
|
u32 len;
|
|
|
|
int rc;
|
|
|
|
|
ACPI APEI: Convert atomicio routines
APEI needs memory access in interrupt context. The obvious choice is
acpi_read(), but originally it couldn't be used in interrupt context
because it makes temporary mappings with ioremap(). Therefore, we added
drivers/acpi/atomicio.c, which provides:
acpi_pre_map_gar() -- ioremap in process context
acpi_atomic_read() -- memory access in interrupt context
acpi_post_unmap_gar() -- iounmap
Later we added acpi_os_map_generic_address() (2971852) and enhanced
acpi_read() so it works in interrupt context as long as the address has
been previously mapped (620242a). Now this sequence:
acpi_os_map_generic_address() -- ioremap in process context
acpi_read()/apei_read() -- now OK in interrupt context
acpi_os_unmap_generic_address()
is equivalent to what atomicio.c provides.
This patch introduces apei_read() and apei_write(), which currently are
functional equivalents of acpi_read() and acpi_write(). This is mainly
proactive, to prevent APEI breakages if acpi_read() and acpi_write()
are ever augmented to support the 'bit_offset' field of GAS, as APEI's
__apei_exec_write_register() precludes splitting up functionality
related to 'bit_offset' and APEI's 'mask' (see its
APEI_EXEC_PRESERVE_REGISTER block).
With apei_read() and apei_write() in place, usages of atomicio routines
are converted to apei_read()/apei_write() and existing calls within
osl.c and the CA, based on the re-factoring that was done in an earlier
patch series - http://marc.info/?l=linux-acpi&m=128769263327206&w=2:
acpi_pre_map_gar() --> acpi_os_map_generic_address()
acpi_post_unmap_gar() --> acpi_os_unmap_generic_address()
acpi_atomic_read() --> apei_read()
acpi_atomic_write() --> apei_write()
Note that acpi_read() and acpi_write() currently use 'bit_width'
for accessing GARs which seems incorrect. 'bit_width' is the size of
the register, while 'access_width' is the size of the access the
processor must generate on the bus. The 'access_width' may be larger,
for example, if the hardware only supports 32-bit or 64-bit reads. I
wanted to minimize any possible impacts with this patch series so I
did *not* change this behavior.
Signed-off-by: Myron Stowe <myron.stowe@redhat.com>
Signed-off-by: Len Brown <len.brown@intel.com>
2011-11-08 07:23:41 +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) {
|
|
|
|
if (!silent && printk_ratelimit())
|
|
|
|
pr_warning(FW_WARN GHES_PFX
|
|
|
|
"Failed to read error status block address for hardware error source: %d.\n",
|
|
|
|
g->header.source_id);
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
if (!buf_paddr)
|
|
|
|
return -ENOENT;
|
|
|
|
|
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_copy_tofrom_phys(ghes->estatus, buf_paddr,
|
|
|
|
sizeof(*ghes->estatus), 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
|
|
|
if (!ghes->estatus->block_status)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
ghes->buffer_paddr = buf_paddr;
|
|
|
|
ghes->flags |= GHES_TO_CLEAR;
|
|
|
|
|
|
|
|
rc = -EIO;
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(ghes->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
|
|
|
if (len < sizeof(*ghes->estatus))
|
|
|
|
goto err_read_block;
|
|
|
|
if (len > ghes->generic->error_block_length)
|
|
|
|
goto err_read_block;
|
2013-10-19 05:28:59 +08:00
|
|
|
if (cper_estatus_check_header(ghes->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
|
|
|
goto err_read_block;
|
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_copy_tofrom_phys(ghes->estatus + 1,
|
|
|
|
buf_paddr + sizeof(*ghes->estatus),
|
|
|
|
len - sizeof(*ghes->estatus), 1);
|
2013-10-19 05:28:59 +08:00
|
|
|
if (cper_estatus_check(ghes->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
|
|
|
goto err_read_block;
|
|
|
|
rc = 0;
|
|
|
|
|
|
|
|
err_read_block:
|
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 && !silent && printk_ratelimit())
|
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_warning(FW_WARN GHES_PFX
|
|
|
|
"Failed to read error status block!\n");
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_clear_estatus(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
ghes->estatus->block_status = 0;
|
|
|
|
if (!(ghes->flags & GHES_TO_CLEAR))
|
|
|
|
return;
|
|
|
|
ghes_copy_tofrom_phys(ghes->estatus, ghes->buffer_paddr,
|
|
|
|
sizeof(ghes->estatus->block_status), 0);
|
|
|
|
ghes->flags &= ~GHES_TO_CLEAR;
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
memory_failure_queue(pfn, 0, flags);
|
2013-07-10 17:27:01 +08:00
|
|
|
#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;
|
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-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);
|
|
|
|
|
2013-02-15 17:10:39 +08:00
|
|
|
ghes_edac_report_mem_error(ghes, sev, mem_err);
|
|
|
|
|
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
|
|
|
}
|
2011-12-08 11:25:41 +08:00
|
|
|
#ifdef CONFIG_ACPI_APEI_PCIEAER
|
2017-06-06 00:40:43 +08:00
|
|
|
else if (guid_equal(sec_type, &CPER_SEC_PCIE)) {
|
2017-06-22 02:17:05 +08:00
|
|
|
struct cper_sec_pcie *pcie_err = acpi_hest_get_payload(gdata);
|
|
|
|
|
2011-12-08 11:25:41 +08:00
|
|
|
if (sev == GHES_SEV_RECOVERABLE &&
|
|
|
|
sec_sev == GHES_SEV_RECOVERABLE &&
|
|
|
|
pcie_err->validation_bits & CPER_PCIE_VALID_DEVICE_ID &&
|
|
|
|
pcie_err->validation_bits & CPER_PCIE_VALID_AER_INFO) {
|
|
|
|
unsigned int devfn;
|
|
|
|
int aer_severity;
|
2013-06-07 02:10:50 +08:00
|
|
|
|
2011-12-08 11:25:41 +08:00
|
|
|
devfn = PCI_DEVFN(pcie_err->device_id.device,
|
|
|
|
pcie_err->device_id.function);
|
2016-09-15 05:14:46 +08:00
|
|
|
aer_severity = cper_severity_to_aer(gdata->error_severity);
|
2013-06-07 02:10:50 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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;
|
|
|
|
|
2011-12-08 11:25:41 +08:00
|
|
|
aer_recover_queue(pcie_err->device_id.segment,
|
|
|
|
pcie_err->device_id.bus,
|
2013-05-30 22:25:12 +08:00
|
|
|
devfn, aer_severity,
|
|
|
|
(struct aer_capability_regs *)
|
|
|
|
pcie_err->aer_info);
|
2011-12-08 11:25:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
#endif
|
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
|
|
|
}
|
|
|
|
|
2017-06-22 02:17:04 +08:00
|
|
|
static int 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 rc;
|
|
|
|
|
|
|
|
val &= gv2->read_ack_preserve << gv2->read_ack_register.bit_offset;
|
|
|
|
val |= gv2->read_ack_write << gv2->read_ack_register.bit_offset;
|
|
|
|
|
|
|
|
return 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 int ghes_proc(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = ghes_read_estatus(ghes, 0);
|
|
|
|
if (rc)
|
|
|
|
goto out;
|
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(ghes->estatus)) {
|
|
|
|
if (ghes_print_estatus(NULL, ghes->generic, ghes->estatus))
|
|
|
|
ghes_estatus_cache_add(ghes->generic, ghes->estatus);
|
|
|
|
}
|
2013-02-15 17:10:39 +08:00
|
|
|
ghes_do_proc(ghes, ghes->estatus);
|
2017-06-22 02:17:04 +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)) {
|
|
|
|
rc = ghes_ack_error(ghes->generic_v2);
|
|
|
|
if (rc)
|
|
|
|
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
|
|
|
out:
|
|
|
|
ghes_clear_estatus(ghes);
|
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);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_poll_func(unsigned long data)
|
|
|
|
{
|
|
|
|
struct ghes *ghes = (void *)data;
|
|
|
|
|
|
|
|
ghes_proc(ghes);
|
|
|
|
if (!(ghes->flags & GHES_EXITING))
|
|
|
|
ghes_add_timer(ghes);
|
|
|
|
}
|
|
|
|
|
|
|
|
static irqreturn_t ghes_irq_func(int irq, void *data)
|
|
|
|
{
|
|
|
|
struct ghes *ghes = data;
|
|
|
|
int rc;
|
|
|
|
|
|
|
|
rc = ghes_proc(ghes);
|
|
|
|
if (rc)
|
|
|
|
return IRQ_NONE;
|
|
|
|
|
|
|
|
return IRQ_HANDLED;
|
|
|
|
}
|
|
|
|
|
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_notify_sci(struct notifier_block *this,
|
|
|
|
unsigned long event, void *data)
|
|
|
|
{
|
|
|
|
struct ghes *ghes;
|
|
|
|
int ret = NOTIFY_DONE;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
list_for_each_entry_rcu(ghes, &ghes_sci, list) {
|
|
|
|
if (!ghes_proc(ghes))
|
|
|
|
ret = NOTIFY_OK;
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-07-22 17:20:12 +08:00
|
|
|
static struct notifier_block ghes_notifier_sci = {
|
|
|
|
.notifier_call = ghes_notify_sci,
|
|
|
|
};
|
|
|
|
|
|
|
|
#ifdef CONFIG_HAVE_ACPI_APEI_NMI
|
|
|
|
/*
|
|
|
|
* printk is not safe in NMI context. So in NMI handler, we allocate
|
|
|
|
* required memory from lock-less memory allocator
|
|
|
|
* (ghes_estatus_pool), save estatus into it, put them into lock-less
|
|
|
|
* list (ghes_estatus_llist), then delay printk into IRQ context via
|
|
|
|
* irq_work (ghes_proc_irq_work). ghes_estatus_size_request record
|
|
|
|
* required pool size by all NMI error source.
|
|
|
|
*/
|
|
|
|
static struct llist_head ghes_estatus_llist;
|
|
|
|
static struct irq_work ghes_proc_irq_work;
|
|
|
|
|
|
|
|
/*
|
2015-03-27 17:05:00 +08:00
|
|
|
* NMI may be triggered on any CPU, so ghes_in_nmi is used for
|
|
|
|
* having only one concurrent reader.
|
2014-07-22 17:20:12 +08:00
|
|
|
*/
|
2015-03-27 17:05:00 +08:00
|
|
|
static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
|
2014-07-22 17:20:12 +08:00
|
|
|
|
|
|
|
static LIST_HEAD(ghes_nmi);
|
|
|
|
|
|
|
|
static int ghes_panic_timeout __read_mostly = 30;
|
|
|
|
|
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
|
|
|
u32 len, node_len;
|
|
|
|
|
|
|
|
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);
|
2013-10-19 05:28:59 +08:00
|
|
|
len = cper_estatus_len(estatus);
|
2011-12-08 11:25:45 +08:00
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(len);
|
|
|
|
generic = estatus_node->generic;
|
|
|
|
ghes_print_estatus(NULL, generic, estatus);
|
|
|
|
llnode = llnode->next;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-03-18 16:41:35 +08:00
|
|
|
/* Save estatus for further processing in IRQ context */
|
|
|
|
static void __process_error(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
|
|
|
|
u32 len, node_len;
|
|
|
|
struct ghes_estatus_node *estatus_node;
|
|
|
|
struct acpi_hest_generic_status *estatus;
|
|
|
|
|
|
|
|
if (ghes_estatus_cached(ghes->estatus))
|
|
|
|
return;
|
|
|
|
|
|
|
|
len = cper_estatus_len(ghes->estatus);
|
|
|
|
node_len = GHES_ESTATUS_NODE_LEN(len);
|
|
|
|
|
|
|
|
estatus_node = (void *)gen_pool_alloc(ghes_estatus_pool, node_len);
|
|
|
|
if (!estatus_node)
|
|
|
|
return;
|
|
|
|
|
|
|
|
estatus_node->ghes = ghes;
|
|
|
|
estatus_node->generic = ghes->generic;
|
|
|
|
estatus = GHES_ESTATUS_FROM_NODE(estatus_node);
|
|
|
|
memcpy(estatus, ghes->estatus, len);
|
|
|
|
llist_add(&estatus_node->llnode, &ghes_estatus_llist);
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2015-03-18 16:52:39 +08:00
|
|
|
static void __ghes_panic(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
oops_begin();
|
|
|
|
ghes_print_queued_estatus();
|
|
|
|
__ghes_print_estatus(KERN_EMERG, ghes->generic, ghes->estatus);
|
|
|
|
|
|
|
|
/* reboot to log the error! */
|
|
|
|
if (panic_timeout == 0)
|
|
|
|
panic_timeout = ghes_panic_timeout;
|
|
|
|
panic("Fatal hardware error!");
|
|
|
|
}
|
|
|
|
|
2011-10-01 03:06:21 +08:00
|
|
|
static int ghes_notify_nmi(unsigned int cmd, struct pt_regs *regs)
|
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
|
|
|
{
|
2015-03-18 16:55:21 +08:00
|
|
|
struct ghes *ghes;
|
|
|
|
int sev, ret = NMI_DONE;
|
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
|
|
|
|
2015-03-27 17:05:00 +08:00
|
|
|
if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
|
|
|
|
return ret;
|
|
|
|
|
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
|
|
|
list_for_each_entry_rcu(ghes, &ghes_nmi, list) {
|
|
|
|
if (ghes_read_estatus(ghes, 1)) {
|
|
|
|
ghes_clear_estatus(ghes);
|
|
|
|
continue;
|
2016-11-30 21:19:39 +08:00
|
|
|
} else {
|
|
|
|
ret = NMI_HANDLED;
|
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
|
|
|
}
|
2015-03-18 16:55:21 +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
|
|
|
sev = ghes_severity(ghes->estatus->error_severity);
|
2015-03-18 16:55:21 +08:00
|
|
|
if (sev >= GHES_SEV_PANIC)
|
|
|
|
__ghes_panic(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
|
|
|
if (!(ghes->flags & GHES_TO_CLEAR))
|
|
|
|
continue;
|
2015-03-18 16:41:35 +08:00
|
|
|
|
|
|
|
__process_error(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
|
|
|
ghes_clear_estatus(ghes);
|
|
|
|
}
|
2015-03-18 16:41:35 +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
|
|
|
#ifdef CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG
|
2016-11-30 21:19:39 +08:00
|
|
|
if (ret == NMI_HANDLED)
|
|
|
|
irq_work_queue(&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
|
|
|
#endif
|
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;
|
|
|
|
}
|
|
|
|
|
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 unsigned long ghes_esource_prealloc_size(
|
|
|
|
const struct acpi_hest_generic *generic)
|
|
|
|
{
|
|
|
|
unsigned long block_length, prealloc_records, prealloc_size;
|
|
|
|
|
|
|
|
block_length = min_t(unsigned long, generic->error_block_length,
|
|
|
|
GHES_ESTATUS_MAX_SIZE);
|
|
|
|
prealloc_records = max_t(unsigned long,
|
|
|
|
generic->records_to_preallocate, 1);
|
|
|
|
prealloc_size = min_t(unsigned long, block_length * prealloc_records,
|
|
|
|
GHES_ESOURCE_PREALLOC_MAX_SIZE);
|
|
|
|
|
|
|
|
return prealloc_size;
|
|
|
|
}
|
|
|
|
|
2014-07-22 17:20:12 +08:00
|
|
|
static void ghes_estatus_pool_shrink(unsigned long len)
|
|
|
|
{
|
|
|
|
ghes_estatus_pool_size_request -= PAGE_ALIGN(len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_nmi_add(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
unsigned long len;
|
|
|
|
|
|
|
|
len = ghes_esource_prealloc_size(ghes->generic);
|
|
|
|
ghes_estatus_pool_expand(len);
|
|
|
|
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)
|
|
|
|
{
|
|
|
|
unsigned long len;
|
|
|
|
|
|
|
|
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();
|
|
|
|
len = ghes_esource_prealloc_size(ghes->generic);
|
|
|
|
ghes_estatus_pool_shrink(len);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ghes_nmi_init_cxt(void)
|
|
|
|
{
|
|
|
|
init_irq_work(&ghes_proc_irq_work, ghes_proc_in_irq);
|
|
|
|
}
|
|
|
|
#else /* CONFIG_HAVE_ACPI_APEI_NMI */
|
|
|
|
static inline void ghes_nmi_add(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
pr_err(GHES_PFX "ID: %d, trying to add NMI notification which is not supported!\n",
|
|
|
|
ghes->generic->header.source_id);
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void ghes_nmi_remove(struct ghes *ghes)
|
|
|
|
{
|
|
|
|
pr_err(GHES_PFX "ID: %d, trying to remove NMI notification which is not supported!\n",
|
|
|
|
ghes->generic->header.source_id);
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void ghes_nmi_init_cxt(void)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_HAVE_ACPI_APEI_NMI */
|
|
|
|
|
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;
|
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:
|
2014-07-22 17:20:12 +08:00
|
|
|
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
|
|
|
|
|
|
|
rc = ghes_edac_register(ghes, &ghes_dev->dev);
|
|
|
|
if (rc < 0)
|
|
|
|
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
|
|
|
switch (generic->notify.type) {
|
|
|
|
case ACPI_HEST_NOTIFY_POLLED:
|
2017-04-19 02:45:28 +08:00
|
|
|
setup_deferrable_timer(&ghes->timer, ghes_poll_func,
|
|
|
|
(unsigned long)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
|
|
|
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);
|
2013-02-15 17:10:39 +08:00
|
|
|
goto err_edac_unreg;
|
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
|
|
|
}
|
2013-06-03 10:08:39 +08:00
|
|
|
rc = request_irq(ghes->irq, ghes_irq_func, 0, "GHES IRQ", ghes);
|
|
|
|
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);
|
2013-02-15 17:10:39 +08:00
|
|
|
goto err_edac_unreg;
|
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_SCI:
|
2010-08-02 15:48:24 +08:00
|
|
|
mutex_lock(&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
|
|
|
if (list_empty(&ghes_sci))
|
|
|
|
register_acpi_hed_notifier(&ghes_notifier_sci);
|
|
|
|
list_add_rcu(&ghes->list, &ghes_sci);
|
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;
|
|
|
|
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
|
|
|
}
|
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
|
|
|
|
|
|
|
return 0;
|
2013-02-15 17:10:39 +08:00
|
|
|
err_edac_unreg:
|
|
|
|
ghes_edac_unregister(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:
|
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;
|
2010-08-02 15:48:24 +08:00
|
|
|
case ACPI_HEST_NOTIFY_SCI:
|
|
|
|
mutex_lock(&ghes_list_mutex);
|
|
|
|
list_del_rcu(&ghes->list);
|
|
|
|
if (list_empty(&ghes_sci))
|
|
|
|
unregister_acpi_hed_notifier(&ghes_notifier_sci);
|
|
|
|
mutex_unlock(&ghes_list_mutex);
|
2017-03-16 22:30:39 +08:00
|
|
|
synchronize_rcu();
|
2010-08-02 15:48:24 +08:00
|
|
|
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;
|
|
|
|
|
|
|
|
if (hest_disable) {
|
|
|
|
pr_info(GHES_PFX "HEST is not enabled!\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
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_ioremap_init();
|
|
|
|
if (rc)
|
|
|
|
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
|
|
|
rc = ghes_estatus_pool_init();
|
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)
|
|
|
|
goto err_ioremap_exit;
|
|
|
|
|
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
|
|
|
rc = ghes_estatus_pool_expand(GHES_ESTATUS_CACHE_AVG_SIZE *
|
|
|
|
GHES_ESTATUS_CACHE_ALLOCED_MAX);
|
|
|
|
if (rc)
|
|
|
|
goto err_pool_exit;
|
|
|
|
|
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)
|
|
|
|
goto err_pool_exit;
|
|
|
|
|
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;
|
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
|
|
|
err_pool_exit:
|
|
|
|
ghes_estatus_pool_exit();
|
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
|
|
|
err_ioremap_exit:
|
|
|
|
ghes_ioremap_exit();
|
|
|
|
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);
|