2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* Machine check handler.
|
|
|
|
* K8 parts Copyright 2002,2003 Andi Kleen, SuSE Labs.
|
|
|
|
* Rest from unknown author(s).
|
|
|
|
* 2004 Andi Kleen. Rewrote most of it.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/sched.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/rcupdate.h>
|
|
|
|
#include <linux/kallsyms.h>
|
|
|
|
#include <linux/sysdev.h>
|
|
|
|
#include <linux/miscdevice.h>
|
|
|
|
#include <linux/fs.h>
|
2006-01-11 13:17:48 -07:00
|
|
|
#include <linux/capability.h>
|
2005-07-28 21:15:39 -07:00
|
|
|
#include <linux/cpu.h>
|
|
|
|
#include <linux/percpu.h>
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
#include <linux/poll.h>
|
|
|
|
#include <linux/thread_info.h>
|
2005-09-12 09:49:24 -07:00
|
|
|
#include <linux/ctype.h>
|
2007-02-13 05:26:23 -07:00
|
|
|
#include <linux/kmod.h>
|
2007-05-08 00:27:03 -07:00
|
|
|
#include <linux/kdebug.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <asm/processor.h>
|
|
|
|
#include <asm/msr.h>
|
|
|
|
#include <asm/mce.h>
|
|
|
|
#include <asm/uaccess.h>
|
2006-01-11 14:46:54 -07:00
|
|
|
#include <asm/smp.h>
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
#include <asm/idle.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
#define MISC_MCELOG_MINOR 227
|
2006-01-11 14:43:06 -07:00
|
|
|
#define NR_BANKS 6
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-07 10:49:57 -07:00
|
|
|
atomic_t mce_entry;
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
static int mce_dont_init;
|
|
|
|
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
/*
|
|
|
|
* Tolerant levels:
|
|
|
|
* 0: always panic on uncorrected errors, log corrected errors
|
|
|
|
* 1: panic or SIGBUS on uncorrected errors, log corrected errors
|
|
|
|
* 2: SIGBUS or log uncorrected errors (if possible), log corrected errors
|
|
|
|
* 3: never panic or SIGBUS, log all errors (for testing only)
|
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
static int tolerant = 1;
|
|
|
|
static int banks;
|
|
|
|
static unsigned long bank[NR_BANKS] = { [0 ... NR_BANKS-1] = ~0UL };
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
static unsigned long notify_user;
|
2005-04-16 15:25:09 -07:00
|
|
|
static int rip_msr;
|
2005-11-05 09:25:54 -07:00
|
|
|
static int mce_bootlog = 1;
|
2007-02-13 05:26:23 -07:00
|
|
|
static atomic_t mce_events;
|
|
|
|
|
|
|
|
static char trigger[128];
|
|
|
|
static char *trigger_argv[2] = { trigger, NULL };
|
2005-04-16 15:20:36 -07:00
|
|
|
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
static DECLARE_WAIT_QUEUE_HEAD(mce_wait);
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* Lockless MCE logging infrastructure.
|
|
|
|
* This avoids deadlocks on printk locks without having to break locks. Also
|
|
|
|
* separate MCEs from kernel messages to avoid bogus bug reports.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct mce_log mcelog = {
|
|
|
|
MCE_LOG_SIGNATURE,
|
|
|
|
MCE_LOG_LEN,
|
|
|
|
};
|
|
|
|
|
|
|
|
void mce_log(struct mce *mce)
|
|
|
|
{
|
|
|
|
unsigned next, entry;
|
2007-02-13 05:26:23 -07:00
|
|
|
atomic_inc(&mce_events);
|
2005-04-16 15:20:36 -07:00
|
|
|
mce->finished = 0;
|
2005-09-29 15:01:27 -07:00
|
|
|
wmb();
|
2005-04-16 15:20:36 -07:00
|
|
|
for (;;) {
|
|
|
|
entry = rcu_dereference(mcelog.next);
|
2005-09-29 15:01:27 -07:00
|
|
|
/* The rmb forces the compiler to reload next in each
|
|
|
|
iteration */
|
|
|
|
rmb();
|
2005-09-12 09:49:24 -07:00
|
|
|
for (;;) {
|
|
|
|
/* When the buffer fills up discard new entries. Assume
|
|
|
|
that the earlier errors are the more interesting. */
|
|
|
|
if (entry >= MCE_LOG_LEN) {
|
|
|
|
set_bit(MCE_OVERFLOW, &mcelog.flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
/* Old left over entry. Skip. */
|
|
|
|
if (mcelog.entry[entry].finished) {
|
|
|
|
entry++;
|
|
|
|
continue;
|
|
|
|
}
|
2005-09-29 15:01:27 -07:00
|
|
|
break;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
smp_rmb();
|
|
|
|
next = entry + 1;
|
|
|
|
if (cmpxchg(&mcelog.next, entry, next) == entry)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
memcpy(mcelog.entry + entry, mce, sizeof(struct mce));
|
2005-09-29 15:01:27 -07:00
|
|
|
wmb();
|
2005-04-16 15:20:36 -07:00
|
|
|
mcelog.entry[entry].finished = 1;
|
2005-09-29 15:01:27 -07:00
|
|
|
wmb();
|
2005-04-16 15:20:36 -07:00
|
|
|
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
set_bit(0, ¬ify_user);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void print_mce(struct mce *m)
|
|
|
|
{
|
|
|
|
printk(KERN_EMERG "\n"
|
2006-01-11 14:44:48 -07:00
|
|
|
KERN_EMERG "HARDWARE ERROR\n"
|
2005-04-16 15:20:36 -07:00
|
|
|
KERN_EMERG
|
|
|
|
"CPU %d: Machine Check Exception: %16Lx Bank %d: %016Lx\n",
|
|
|
|
m->cpu, m->mcgstatus, m->bank, m->status);
|
|
|
|
if (m->rip) {
|
|
|
|
printk(KERN_EMERG
|
|
|
|
"RIP%s %02x:<%016Lx> ",
|
|
|
|
!(m->mcgstatus & MCG_STATUS_EIPV) ? " !INEXACT!" : "",
|
|
|
|
m->cs, m->rip);
|
|
|
|
if (m->cs == __KERNEL_CS)
|
|
|
|
print_symbol("{%s}", m->rip);
|
|
|
|
printk("\n");
|
|
|
|
}
|
|
|
|
printk(KERN_EMERG "TSC %Lx ", m->tsc);
|
|
|
|
if (m->addr)
|
|
|
|
printk("ADDR %Lx ", m->addr);
|
|
|
|
if (m->misc)
|
|
|
|
printk("MISC %Lx ", m->misc);
|
|
|
|
printk("\n");
|
2006-01-11 14:44:48 -07:00
|
|
|
printk(KERN_EMERG "This is not a software problem!\n");
|
|
|
|
printk(KERN_EMERG
|
|
|
|
"Run through mcelog --ascii to decode and contact your hardware vendor\n");
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void mce_panic(char *msg, struct mce *backup, unsigned long start)
|
|
|
|
{
|
|
|
|
int i;
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
oops_begin();
|
|
|
|
for (i = 0; i < MCE_LOG_LEN; i++) {
|
|
|
|
unsigned long tsc = mcelog.entry[i].tsc;
|
|
|
|
if (time_before(tsc, start))
|
|
|
|
continue;
|
|
|
|
print_mce(&mcelog.entry[i]);
|
|
|
|
if (backup && mcelog.entry[i].tsc == backup->tsc)
|
|
|
|
backup = NULL;
|
|
|
|
}
|
|
|
|
if (backup)
|
|
|
|
print_mce(backup);
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
panic(msg);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mce_available(struct cpuinfo_x86 *c)
|
|
|
|
{
|
2006-03-24 04:15:11 -07:00
|
|
|
return cpu_has(c, X86_FEATURE_MCE) && cpu_has(c, X86_FEATURE_MCA);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2005-04-16 15:25:09 -07:00
|
|
|
static inline void mce_get_rip(struct mce *m, struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
if (regs && (m->mcgstatus & MCG_STATUS_RIPV)) {
|
|
|
|
m->rip = regs->rip;
|
|
|
|
m->cs = regs->cs;
|
|
|
|
} else {
|
|
|
|
m->rip = 0;
|
|
|
|
m->cs = 0;
|
|
|
|
}
|
|
|
|
if (rip_msr) {
|
|
|
|
/* Assume the RIP in the MSR is exact. Is this true? */
|
|
|
|
m->mcgstatus |= MCG_STATUS_EIPV;
|
|
|
|
rdmsrl(rip_msr, m->rip);
|
|
|
|
m->cs = 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
|
|
|
* The actual machine check handler
|
|
|
|
*/
|
|
|
|
|
|
|
|
void do_machine_check(struct pt_regs * regs, long error_code)
|
|
|
|
{
|
|
|
|
struct mce m, panicm;
|
|
|
|
u64 mcestart = 0;
|
|
|
|
int i;
|
|
|
|
int panicm_found = 0;
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
/*
|
|
|
|
* If no_way_out gets set, there is no safe way to recover from this
|
|
|
|
* MCE. If tolerant is cranked up, we'll try anyway.
|
|
|
|
*/
|
|
|
|
int no_way_out = 0;
|
|
|
|
/*
|
|
|
|
* If kill_it gets set, there might be a way to recover from this
|
|
|
|
* error.
|
|
|
|
*/
|
|
|
|
int kill_it = 0;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2006-04-07 10:49:57 -07:00
|
|
|
atomic_inc(&mce_entry);
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
if (regs)
|
2006-01-11 14:42:14 -07:00
|
|
|
notify_die(DIE_NMI, "machine check", regs, error_code, 18, SIGKILL);
|
2005-04-16 15:20:36 -07:00
|
|
|
if (!banks)
|
2006-04-07 10:49:57 -07:00
|
|
|
goto out2;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
memset(&m, 0, sizeof(struct mce));
|
2006-09-26 01:52:37 -07:00
|
|
|
m.cpu = smp_processor_id();
|
2005-04-16 15:20:36 -07:00
|
|
|
rdmsrl(MSR_IA32_MCG_STATUS, m.mcgstatus);
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
/* if the restart IP is not valid, we're done for */
|
2005-04-16 15:20:36 -07:00
|
|
|
if (!(m.mcgstatus & MCG_STATUS_RIPV))
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
no_way_out = 1;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
rdtscll(mcestart);
|
|
|
|
barrier();
|
|
|
|
|
|
|
|
for (i = 0; i < banks; i++) {
|
|
|
|
if (!bank[i])
|
|
|
|
continue;
|
|
|
|
|
|
|
|
m.misc = 0;
|
|
|
|
m.addr = 0;
|
|
|
|
m.bank = i;
|
|
|
|
m.tsc = 0;
|
|
|
|
|
|
|
|
rdmsrl(MSR_IA32_MC0_STATUS + i*4, m.status);
|
|
|
|
if ((m.status & MCI_STATUS_VAL) == 0)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (m.status & MCI_STATUS_EN) {
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
/* if PCC was set, there's no way out */
|
|
|
|
no_way_out |= !!(m.status & MCI_STATUS_PCC);
|
|
|
|
/*
|
|
|
|
* If this error was uncorrectable and there was
|
|
|
|
* an overflow, we're in trouble. If no overflow,
|
|
|
|
* we might get away with just killing a task.
|
|
|
|
*/
|
|
|
|
if (m.status & MCI_STATUS_UC) {
|
|
|
|
if (tolerant < 1 || m.status & MCI_STATUS_OVER)
|
|
|
|
no_way_out = 1;
|
|
|
|
kill_it = 1;
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
if (m.status & MCI_STATUS_MISCV)
|
|
|
|
rdmsrl(MSR_IA32_MC0_MISC + i*4, m.misc);
|
|
|
|
if (m.status & MCI_STATUS_ADDRV)
|
|
|
|
rdmsrl(MSR_IA32_MC0_ADDR + i*4, m.addr);
|
|
|
|
|
2005-04-16 15:25:09 -07:00
|
|
|
mce_get_rip(&m, regs);
|
2005-08-07 09:42:07 -07:00
|
|
|
if (error_code >= 0)
|
2005-04-16 15:20:36 -07:00
|
|
|
rdtscll(m.tsc);
|
2005-08-07 09:42:07 -07:00
|
|
|
if (error_code != -2)
|
|
|
|
mce_log(&m);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* Did this bank cause the exception? */
|
|
|
|
/* Assume that the bank with uncorrectable errors did it,
|
|
|
|
and that there is only a single one. */
|
|
|
|
if ((m.status & MCI_STATUS_UC) && (m.status & MCI_STATUS_EN)) {
|
|
|
|
panicm = m;
|
|
|
|
panicm_found = 1;
|
|
|
|
}
|
|
|
|
|
2005-09-13 01:25:16 -07:00
|
|
|
add_taint(TAINT_MACHINE_CHECK);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Never do anything final in the polling timer */
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
if (!regs)
|
2005-04-16 15:20:36 -07:00
|
|
|
goto out;
|
|
|
|
|
|
|
|
/* If we didn't find an uncorrectable error, pick
|
|
|
|
the last one (shouldn't happen, just being safe). */
|
|
|
|
if (!panicm_found)
|
|
|
|
panicm = m;
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we have decided that we just CAN'T continue, and the user
|
|
|
|
* has not set tolerant to an insane level, give up and die.
|
|
|
|
*/
|
|
|
|
if (no_way_out && tolerant < 3)
|
2005-04-16 15:20:36 -07:00
|
|
|
mce_panic("Machine check", &panicm, mcestart);
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the error seems to be unrecoverable, something should be
|
|
|
|
* done. Try to kill as little as possible. If we can kill just
|
|
|
|
* one task, do that. If the user has set the tolerance very
|
|
|
|
* high, don't try to do anything at all.
|
|
|
|
*/
|
|
|
|
if (kill_it && tolerant < 3) {
|
2005-04-16 15:20:36 -07:00
|
|
|
int user_space = 0;
|
|
|
|
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
/*
|
|
|
|
* If the EIPV bit is set, it means the saved IP is the
|
|
|
|
* instruction which caused the MCE.
|
|
|
|
*/
|
|
|
|
if (m.mcgstatus & MCG_STATUS_EIPV)
|
2005-04-16 15:20:36 -07:00
|
|
|
user_space = panicm.rip && (panicm.cs & 3);
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If we know that the error was in user space, send a
|
|
|
|
* SIGBUS. Otherwise, panic if tolerance is low.
|
|
|
|
*
|
|
|
|
* do_exit() takes an awful lot of locks and has a slight
|
|
|
|
* risk of deadlocking.
|
|
|
|
*/
|
|
|
|
if (user_space) {
|
2005-04-16 15:20:36 -07:00
|
|
|
do_exit(SIGBUS);
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
} else if (panic_on_oops || tolerant < 2) {
|
|
|
|
mce_panic("Uncorrected machine check",
|
|
|
|
&panicm, mcestart);
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
/* notify userspace ASAP */
|
|
|
|
set_thread_flag(TIF_MCE_NOTIFY);
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
out:
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
/* the last thing we do is clear state */
|
|
|
|
for (i = 0; i < banks; i++)
|
|
|
|
wrmsrl(MSR_IA32_MC0_STATUS+4*i, 0);
|
2005-04-16 15:20:36 -07:00
|
|
|
wrmsrl(MSR_IA32_MCG_STATUS, 0);
|
2006-04-07 10:49:57 -07:00
|
|
|
out2:
|
|
|
|
atomic_dec(&mce_entry);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2006-09-26 01:52:42 -07:00
|
|
|
#ifdef CONFIG_X86_MCE_INTEL
|
|
|
|
/***
|
|
|
|
* mce_log_therm_throt_event - Logs the thermal throttling event to mcelog
|
|
|
|
* @cpu: The CPU on which the event occured.
|
|
|
|
* @status: Event status information
|
|
|
|
*
|
|
|
|
* This function should be called by the thermal interrupt after the
|
|
|
|
* event has been processed and the decision was made to log the event
|
|
|
|
* further.
|
|
|
|
*
|
|
|
|
* The status parameter will be saved to the 'status' field of 'struct mce'
|
|
|
|
* and historically has been the register value of the
|
|
|
|
* MSR_IA32_THERMAL_STATUS (Intel) msr.
|
|
|
|
*/
|
|
|
|
void mce_log_therm_throt_event(unsigned int cpu, __u64 status)
|
|
|
|
{
|
|
|
|
struct mce m;
|
|
|
|
|
|
|
|
memset(&m, 0, sizeof(m));
|
|
|
|
m.cpu = cpu;
|
|
|
|
m.bank = MCE_THERMAL_BANK;
|
|
|
|
m.status = status;
|
|
|
|
rdtscll(m.tsc);
|
|
|
|
mce_log(&m);
|
|
|
|
}
|
|
|
|
#endif /* CONFIG_X86_MCE_INTEL */
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
/*
|
2007-05-02 10:27:19 -07:00
|
|
|
* Periodic polling timer for "silent" machine check errors. If the
|
|
|
|
* poller finds an MCE, poll 2x faster. When the poller finds no more
|
|
|
|
* errors, poll 2x slower (up to check_interval seconds).
|
2005-04-16 15:20:36 -07:00
|
|
|
*/
|
|
|
|
|
|
|
|
static int check_interval = 5 * 60; /* 5 minutes */
|
2007-05-02 10:27:19 -07:00
|
|
|
static int next_interval; /* in jiffies */
|
2006-11-22 07:55:48 -07:00
|
|
|
static void mcheck_timer(struct work_struct *work);
|
|
|
|
static DECLARE_DELAYED_WORK(mcheck_work, mcheck_timer);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
static void mcheck_check_cpu(void *info)
|
|
|
|
{
|
|
|
|
if (mce_available(¤t_cpu_data))
|
|
|
|
do_machine_check(NULL, 0);
|
|
|
|
}
|
|
|
|
|
2006-11-22 07:55:48 -07:00
|
|
|
static void mcheck_timer(struct work_struct *work)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
on_each_cpu(mcheck_check_cpu, NULL, 1, 1);
|
|
|
|
|
|
|
|
/*
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
* Alert userspace if needed. If we logged an MCE, reduce the
|
|
|
|
* polling interval, otherwise increase the polling interval.
|
2005-04-16 15:20:36 -07:00
|
|
|
*/
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
if (mce_notify_user()) {
|
|
|
|
next_interval = max(next_interval/2, HZ/100);
|
|
|
|
} else {
|
2007-07-21 08:10:44 -07:00
|
|
|
next_interval = min(next_interval*2,
|
|
|
|
(int)round_jiffies_relative(check_interval*HZ));
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
schedule_delayed_work(&mcheck_work, next_interval);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This is only called from process context. This is where we do
|
|
|
|
* anything we need to alert userspace about new MCEs. This is called
|
|
|
|
* directly from the poller and also from entry.S and idle, thanks to
|
|
|
|
* TIF_MCE_NOTIFY.
|
|
|
|
*/
|
|
|
|
int mce_notify_user(void)
|
|
|
|
{
|
|
|
|
clear_thread_flag(TIF_MCE_NOTIFY);
|
|
|
|
if (test_and_clear_bit(0, ¬ify_user)) {
|
2007-05-02 10:27:19 -07:00
|
|
|
static unsigned long last_print;
|
|
|
|
unsigned long now = jiffies;
|
|
|
|
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
wake_up_interruptible(&mce_wait);
|
|
|
|
if (trigger[0])
|
|
|
|
call_usermodehelper(trigger, trigger_argv, NULL,
|
|
|
|
UMH_NO_WAIT);
|
|
|
|
|
2007-05-02 10:27:19 -07:00
|
|
|
if (time_after_eq(now, last_print + (check_interval*HZ))) {
|
|
|
|
last_print = now;
|
|
|
|
printk(KERN_INFO "Machine check events logged\n");
|
|
|
|
}
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
|
|
|
|
return 1;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
return 0;
|
|
|
|
}
|
2007-05-02 10:27:19 -07:00
|
|
|
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
/* see if the idle task needs to notify userspace */
|
|
|
|
static int
|
|
|
|
mce_idle_callback(struct notifier_block *nfb, unsigned long action, void *junk)
|
|
|
|
{
|
|
|
|
/* IDLE_END should be safe - interrupts are back on */
|
|
|
|
if (action == IDLE_END && test_thread_flag(TIF_MCE_NOTIFY))
|
|
|
|
mce_notify_user();
|
|
|
|
|
|
|
|
return NOTIFY_OK;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
static struct notifier_block mce_idle_notifier = {
|
|
|
|
.notifier_call = mce_idle_callback,
|
|
|
|
};
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
static __init int periodic_mcheck_init(void)
|
|
|
|
{
|
2007-05-02 10:27:19 -07:00
|
|
|
next_interval = check_interval * HZ;
|
|
|
|
if (next_interval)
|
2007-07-21 08:10:44 -07:00
|
|
|
schedule_delayed_work(&mcheck_work,
|
|
|
|
round_jiffies_relative(next_interval));
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
idle_notifier_register(&mce_idle_notifier);
|
2005-04-16 15:20:36 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
__initcall(periodic_mcheck_init);
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Initialize Machine Checks for a CPU.
|
|
|
|
*/
|
|
|
|
static void mce_init(void *dummy)
|
|
|
|
{
|
|
|
|
u64 cap;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
rdmsrl(MSR_IA32_MCG_CAP, cap);
|
|
|
|
banks = cap & 0xff;
|
|
|
|
if (banks > NR_BANKS) {
|
|
|
|
printk(KERN_INFO "MCE: warning: using only %d banks\n", banks);
|
|
|
|
banks = NR_BANKS;
|
|
|
|
}
|
2005-04-16 15:25:09 -07:00
|
|
|
/* Use accurate RIP reporting if available. */
|
|
|
|
if ((cap & (1<<9)) && ((cap >> 16) & 0xff) >= 9)
|
|
|
|
rip_msr = MSR_IA32_MCG_EIP;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* Log the machine checks left over from the previous reset.
|
|
|
|
This also clears all registers */
|
2005-08-07 09:42:07 -07:00
|
|
|
do_machine_check(NULL, mce_bootlog ? -1 : -2);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
set_in_cr4(X86_CR4_MCE);
|
|
|
|
|
|
|
|
if (cap & MCG_CTL_P)
|
|
|
|
wrmsr(MSR_IA32_MCG_CTL, 0xffffffff, 0xffffffff);
|
|
|
|
|
|
|
|
for (i = 0; i < banks; i++) {
|
|
|
|
wrmsrl(MSR_IA32_MC0_CTL+4*i, bank[i]);
|
|
|
|
wrmsrl(MSR_IA32_MC0_STATUS+4*i, 0);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Add per CPU specific workarounds here */
|
[PATCH] x86_64: Change init sections for CPU hotplug support
This patch adds __cpuinit and __cpuinitdata sections that need to exist past
boot to support cpu hotplug.
Caveat: This is done *only* for EM64T CPU Hotplug support, on request from
Andi Kleen. Much of the generic hotplug code in kernel, and none of the other
archs that support CPU hotplug today, i386, ia64, ppc64, s390 and parisc dont
mark sections with __cpuinit, but only mark them as __devinit, and
__devinitdata.
If someone is motivated to change generic code, we need to make sure all
existing hotplug code does not break, on other arch's that dont use __cpuinit,
and __cpudevinit.
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Acked-by: Andi Kleen <ak@muc.de>
Acked-by: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 14:54:58 -07:00
|
|
|
static void __cpuinit mce_cpu_quirks(struct cpuinfo_x86 *c)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
/* This should be disabled by the BIOS, but isn't always */
|
|
|
|
if (c->x86_vendor == X86_VENDOR_AMD && c->x86 == 15) {
|
|
|
|
/* disable GART TBL walk error reporting, which trips off
|
|
|
|
incorrectly with the IOMMU & 3ware & Cerberus. */
|
|
|
|
clear_bit(10, &bank[4]);
|
2005-11-05 09:25:54 -07:00
|
|
|
/* Lots of broken BIOS around that don't clear them
|
|
|
|
by default and leave crap in there. Don't log. */
|
|
|
|
mce_bootlog = 0;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
2005-11-05 09:25:54 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
[PATCH] x86_64: Change init sections for CPU hotplug support
This patch adds __cpuinit and __cpuinitdata sections that need to exist past
boot to support cpu hotplug.
Caveat: This is done *only* for EM64T CPU Hotplug support, on request from
Andi Kleen. Much of the generic hotplug code in kernel, and none of the other
archs that support CPU hotplug today, i386, ia64, ppc64, s390 and parisc dont
mark sections with __cpuinit, but only mark them as __devinit, and
__devinitdata.
If someone is motivated to change generic code, we need to make sure all
existing hotplug code does not break, on other arch's that dont use __cpuinit,
and __cpudevinit.
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Acked-by: Andi Kleen <ak@muc.de>
Acked-by: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 14:54:58 -07:00
|
|
|
static void __cpuinit mce_cpu_features(struct cpuinfo_x86 *c)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
switch (c->x86_vendor) {
|
|
|
|
case X86_VENDOR_INTEL:
|
|
|
|
mce_intel_feature_init(c);
|
|
|
|
break;
|
2005-11-05 09:25:53 -07:00
|
|
|
case X86_VENDOR_AMD:
|
|
|
|
mce_amd_feature_init(c);
|
|
|
|
break;
|
2005-04-16 15:20:36 -07:00
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called for each booted CPU to set up machine checks.
|
|
|
|
* Must be called with preempt off.
|
|
|
|
*/
|
[PATCH] x86_64: Change init sections for CPU hotplug support
This patch adds __cpuinit and __cpuinitdata sections that need to exist past
boot to support cpu hotplug.
Caveat: This is done *only* for EM64T CPU Hotplug support, on request from
Andi Kleen. Much of the generic hotplug code in kernel, and none of the other
archs that support CPU hotplug today, i386, ia64, ppc64, s390 and parisc dont
mark sections with __cpuinit, but only mark them as __devinit, and
__devinitdata.
If someone is motivated to change generic code, we need to make sure all
existing hotplug code does not break, on other arch's that dont use __cpuinit,
and __cpudevinit.
Signed-off-by: Ashok Raj <ashok.raj@intel.com>
Acked-by: Andi Kleen <ak@muc.de>
Acked-by: Zwane Mwaikambo <zwane@arm.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-25 14:54:58 -07:00
|
|
|
void __cpuinit mcheck_init(struct cpuinfo_x86 *c)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2006-02-03 13:51:23 -07:00
|
|
|
static cpumask_t mce_cpus = CPU_MASK_NONE;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
mce_cpu_quirks(c);
|
|
|
|
|
|
|
|
if (mce_dont_init ||
|
|
|
|
cpu_test_and_set(smp_processor_id(), mce_cpus) ||
|
|
|
|
!mce_available(c))
|
|
|
|
return;
|
|
|
|
|
|
|
|
mce_init(NULL);
|
|
|
|
mce_cpu_features(c);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Character device to read and clear the MCE log.
|
|
|
|
*/
|
|
|
|
|
2007-07-21 08:10:35 -07:00
|
|
|
static DEFINE_SPINLOCK(mce_state_lock);
|
|
|
|
static int open_count; /* #times opened */
|
|
|
|
static int open_exclu; /* already open exclusive? */
|
|
|
|
|
|
|
|
static int mce_open(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
spin_lock(&mce_state_lock);
|
|
|
|
|
|
|
|
if (open_exclu || (open_count && (file->f_flags & O_EXCL))) {
|
|
|
|
spin_unlock(&mce_state_lock);
|
|
|
|
return -EBUSY;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (file->f_flags & O_EXCL)
|
|
|
|
open_exclu = 1;
|
|
|
|
open_count++;
|
|
|
|
|
|
|
|
spin_unlock(&mce_state_lock);
|
|
|
|
|
x86_64: mcelog tolerant level cleanup
Background:
The MCE handler has several paths that it can take, depending on various
conditions of the MCE status and the value of the 'tolerant' knob. The
exact semantics are not well defined and the code is a bit twisty.
Description:
This patch makes the MCE handler's behavior more clear by documenting the
behavior for various 'tolerant' levels. It also fixes or enhances
several small things in the handler. Specifically:
* If RIPV is set it is not safe to restart, so set the 'no way out'
flag rather than the 'kill it' flag.
* Don't panic() on correctable MCEs.
* If the _OVER bit is set *and* the _UC bit is set (meaning possibly
dropped uncorrected errors), set the 'no way out' flag.
* Use EIPV for testing whether an app can be killed (SIGBUS) rather
than RIPV. According to docs, EIPV indicates that the error is
related to the IP, while RIPV simply means the IP is valid to
restart from.
* Don't clear the MCi_STATUS registers until after the panic() path.
This leaves the status bits set after the panic() so clever BIOSes
can find them (and dumb BIOSes can do nothing).
This patch also calls nonseekable_open() in mce_open (as suggested by akpm).
Result:
Tolerant levels behave almost identically to how they always have, but
not it's well defined. There's a slightly higher chance of panic()ing
when multiple errors happen (a good thing, IMHO). If you take an MBE and
panic(), the error status bits are not cleared.
Alternatives:
None.
Testing:
I used software to inject correctable and uncorrectable errors. With
tolerant = 3, the system usually survives. With tolerant = 2, the system
usually panic()s (PCC) but not always. With tolerant = 1, the system
always panic()s. When the system panic()s, the BIOS is able to detect
that the cause of death was an MC4. I was not able to reproduce the
case of a non-PCC error in userspace, with EIPV, with (tolerant < 3).
That will be rare at best.
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:37 -07:00
|
|
|
return nonseekable_open(inode, file);
|
2007-07-21 08:10:35 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int mce_release(struct inode *inode, struct file *file)
|
|
|
|
{
|
|
|
|
spin_lock(&mce_state_lock);
|
|
|
|
|
|
|
|
open_count--;
|
|
|
|
open_exclu = 0;
|
|
|
|
|
|
|
|
spin_unlock(&mce_state_lock);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
static void collect_tscs(void *data)
|
|
|
|
{
|
|
|
|
unsigned long *cpu_tsc = (unsigned long *)data;
|
|
|
|
rdtscll(cpu_tsc[smp_processor_id()]);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t mce_read(struct file *filp, char __user *ubuf, size_t usize, loff_t *off)
|
|
|
|
{
|
2005-04-16 15:25:10 -07:00
|
|
|
unsigned long *cpu_tsc;
|
2005-04-16 15:20:36 -07:00
|
|
|
static DECLARE_MUTEX(mce_read_sem);
|
|
|
|
unsigned next;
|
|
|
|
char __user *buf = ubuf;
|
|
|
|
int i, err;
|
|
|
|
|
2005-04-16 15:25:10 -07:00
|
|
|
cpu_tsc = kmalloc(NR_CPUS * sizeof(long), GFP_KERNEL);
|
|
|
|
if (!cpu_tsc)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
down(&mce_read_sem);
|
|
|
|
next = rcu_dereference(mcelog.next);
|
|
|
|
|
|
|
|
/* Only supports full reads right now */
|
|
|
|
if (*off != 0 || usize < MCE_LOG_LEN*sizeof(struct mce)) {
|
|
|
|
up(&mce_read_sem);
|
2005-04-16 15:25:10 -07:00
|
|
|
kfree(cpu_tsc);
|
2005-04-16 15:20:36 -07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = 0;
|
2005-09-12 09:49:24 -07:00
|
|
|
for (i = 0; i < next; i++) {
|
|
|
|
unsigned long start = jiffies;
|
|
|
|
while (!mcelog.entry[i].finished) {
|
2007-06-23 17:16:45 -07:00
|
|
|
if (time_after_eq(jiffies, start + 2)) {
|
2005-09-12 09:49:24 -07:00
|
|
|
memset(mcelog.entry + i,0, sizeof(struct mce));
|
2007-06-23 17:16:45 -07:00
|
|
|
goto timeout;
|
2005-09-12 09:49:24 -07:00
|
|
|
}
|
|
|
|
cpu_relax();
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
smp_rmb();
|
|
|
|
err |= copy_to_user(buf, mcelog.entry + i, sizeof(struct mce));
|
|
|
|
buf += sizeof(struct mce);
|
2007-06-23 17:16:45 -07:00
|
|
|
timeout:
|
|
|
|
;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
memset(mcelog.entry, 0, next * sizeof(struct mce));
|
|
|
|
mcelog.next = 0;
|
|
|
|
|
2005-06-25 14:55:38 -07:00
|
|
|
synchronize_sched();
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* Collect entries that were still getting written before the synchronize. */
|
|
|
|
|
|
|
|
on_each_cpu(collect_tscs, cpu_tsc, 1, 1);
|
|
|
|
for (i = next; i < MCE_LOG_LEN; i++) {
|
|
|
|
if (mcelog.entry[i].finished &&
|
|
|
|
mcelog.entry[i].tsc < cpu_tsc[mcelog.entry[i].cpu]) {
|
|
|
|
err |= copy_to_user(buf, mcelog.entry+i, sizeof(struct mce));
|
|
|
|
smp_rmb();
|
|
|
|
buf += sizeof(struct mce);
|
|
|
|
memset(&mcelog.entry[i], 0, sizeof(struct mce));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
up(&mce_read_sem);
|
2005-04-16 15:25:10 -07:00
|
|
|
kfree(cpu_tsc);
|
2005-04-16 15:20:36 -07:00
|
|
|
return err ? -EFAULT : buf - ubuf;
|
|
|
|
}
|
|
|
|
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
static unsigned int mce_poll(struct file *file, poll_table *wait)
|
|
|
|
{
|
|
|
|
poll_wait(file, &mce_wait, wait);
|
|
|
|
if (rcu_dereference(mcelog.next))
|
|
|
|
return POLLIN | POLLRDNORM;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
static int mce_ioctl(struct inode *i, struct file *f,unsigned int cmd, unsigned long arg)
|
|
|
|
{
|
|
|
|
int __user *p = (int __user *)arg;
|
|
|
|
if (!capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
switch (cmd) {
|
|
|
|
case MCE_GET_RECORD_LEN:
|
|
|
|
return put_user(sizeof(struct mce), p);
|
|
|
|
case MCE_GET_LOG_LEN:
|
|
|
|
return put_user(MCE_LOG_LEN, p);
|
|
|
|
case MCE_GETCLEAR_FLAGS: {
|
|
|
|
unsigned flags;
|
|
|
|
do {
|
|
|
|
flags = mcelog.flags;
|
|
|
|
} while (cmpxchg(&mcelog.flags, flags, 0) != flags);
|
|
|
|
return put_user(flags, p);
|
|
|
|
}
|
|
|
|
default:
|
|
|
|
return -ENOTTY;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-02-12 01:55:31 -07:00
|
|
|
static const struct file_operations mce_chrdev_ops = {
|
2007-07-21 08:10:35 -07:00
|
|
|
.open = mce_open,
|
|
|
|
.release = mce_release,
|
2005-04-16 15:20:36 -07:00
|
|
|
.read = mce_read,
|
x86_64: support poll() on /dev/mcelog
Background:
/dev/mcelog is typically polled manually. This is less than optimal for
situations where accurate accounting of MCEs is important. Calling
poll() on /dev/mcelog does not work.
Description:
This patch adds support for poll() to /dev/mcelog. This results in
immediate wakeup of user apps whenever the poller finds MCEs. Because
the exception handler can not take any locks, it can not call the wakeup
itself. Instead, it uses a thread_info flag (TIF_MCE_NOTIFY) which is
caught at the next return from interrupt or exit from idle, calling the
mce_user_notify() routine. This patch also disables the "fake panic"
path of the mce_panic(), because it results in printk()s in the exception
handler and crashy systems.
This patch also does some small cleanup for essentially unused variables,
and moves the user notification into the body of the poller, so it is
only called once per poll, rather than once per CPU.
Result:
Applications can now poll() on /dev/mcelog. When an error is logged
(whether through the poller or through an exception) the applications are
woken up promptly. This should not affect any previous behaviors. If no
MCEs are being logged, there is no overhead.
Alternatives:
I considered simply supporting poll() through the poller and not using
TIF_MCE_NOTIFY at all. However, the time between an uncorrectable error
happening and the user application being notified is *the*most* critical
window for us. Many uncorrectable errors can be logged to the network if
given a chance.
I also considered doing the MCE poll directly from the idle notifier, but
decided that was overkill.
Testing:
I used an error-injecting DIMM to create lots of correctable DRAM errors
and verified that my user app is woken up in sync with the polling interval.
I also used the northbridge to inject uncorrectable ECC errors, and
verified (printk() to the rescue) that the notify routine is called and the
user app does wake up. I built with PREEMPT on and off, and verified
that my machine survives MCEs.
[wli@holomorphy.com: build fix]
Signed-off-by: Tim Hockin <thockin@google.com>
Signed-off-by: William Irwin <bill.irwin@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Andi Kleen <ak@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-07-21 08:10:36 -07:00
|
|
|
.poll = mce_poll,
|
2005-04-16 15:20:36 -07:00
|
|
|
.ioctl = mce_ioctl,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct miscdevice mce_log_device = {
|
|
|
|
MISC_MCELOG_MINOR,
|
|
|
|
"mcelog",
|
|
|
|
&mce_chrdev_ops,
|
|
|
|
};
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Old style boot options parsing. Only for compatibility.
|
|
|
|
*/
|
|
|
|
|
|
|
|
static int __init mcheck_disable(char *str)
|
|
|
|
{
|
|
|
|
mce_dont_init = 1;
|
2006-03-31 03:30:33 -07:00
|
|
|
return 1;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* mce=off disables machine check. Note you can reenable it later
|
2005-08-07 09:42:07 -07:00
|
|
|
using sysfs.
|
2005-09-12 09:49:24 -07:00
|
|
|
mce=TOLERANCELEVEL (number, see above)
|
2005-11-05 09:25:54 -07:00
|
|
|
mce=bootlog Log MCEs from before booting. Disabled by default on AMD.
|
|
|
|
mce=nobootlog Don't log MCEs from before booting. */
|
2005-04-16 15:20:36 -07:00
|
|
|
static int __init mcheck_enable(char *str)
|
|
|
|
{
|
2005-08-07 09:42:07 -07:00
|
|
|
if (*str == '=')
|
|
|
|
str++;
|
2005-04-16 15:20:36 -07:00
|
|
|
if (!strcmp(str, "off"))
|
|
|
|
mce_dont_init = 1;
|
2005-11-05 09:25:54 -07:00
|
|
|
else if (!strcmp(str, "bootlog") || !strcmp(str,"nobootlog"))
|
|
|
|
mce_bootlog = str[0] == 'b';
|
2005-09-12 09:49:24 -07:00
|
|
|
else if (isdigit(str[0]))
|
|
|
|
get_option(&str, &tolerant);
|
2005-04-16 15:20:36 -07:00
|
|
|
else
|
|
|
|
printk("mce= argument %s ignored. Please use /sys", str);
|
2006-03-31 03:30:33 -07:00
|
|
|
return 1;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
__setup("nomce", mcheck_disable);
|
|
|
|
__setup("mce", mcheck_enable);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Sysfs support
|
|
|
|
*/
|
|
|
|
|
2005-09-12 09:49:24 -07:00
|
|
|
/* On resume clear all MCE state. Don't want to see leftovers from the BIOS.
|
|
|
|
Only one CPU is active at this time, the others get readded later using
|
|
|
|
CPU hotplug. */
|
2005-04-16 15:20:36 -07:00
|
|
|
static int mce_resume(struct sys_device *dev)
|
|
|
|
{
|
2005-09-12 09:49:24 -07:00
|
|
|
mce_init(NULL);
|
2005-04-16 15:20:36 -07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Reinit MCEs after user configuration changes */
|
|
|
|
static void mce_restart(void)
|
|
|
|
{
|
2007-05-02 10:27:19 -07:00
|
|
|
if (next_interval)
|
2005-04-16 15:20:36 -07:00
|
|
|
cancel_delayed_work(&mcheck_work);
|
|
|
|
/* Timer race is harmless here */
|
|
|
|
on_each_cpu(mce_init, NULL, 1, 1);
|
2007-05-02 10:27:19 -07:00
|
|
|
next_interval = check_interval * HZ;
|
|
|
|
if (next_interval)
|
2007-07-21 08:10:44 -07:00
|
|
|
schedule_delayed_work(&mcheck_work,
|
|
|
|
round_jiffies_relative(next_interval));
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct sysdev_class mce_sysclass = {
|
|
|
|
.resume = mce_resume,
|
|
|
|
set_kset_name("machinecheck"),
|
|
|
|
};
|
|
|
|
|
2006-06-26 04:58:50 -07:00
|
|
|
DEFINE_PER_CPU(struct sys_device, device_mce);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
/* Why are there no generic functions for this? */
|
|
|
|
#define ACCESSOR(name, var, start) \
|
|
|
|
static ssize_t show_ ## name(struct sys_device *s, char *buf) { \
|
|
|
|
return sprintf(buf, "%lx\n", (unsigned long)var); \
|
|
|
|
} \
|
|
|
|
static ssize_t set_ ## name(struct sys_device *s,const char *buf,size_t siz) { \
|
|
|
|
char *end; \
|
|
|
|
unsigned long new = simple_strtoul(buf, &end, 0); \
|
|
|
|
if (end == buf) return -EINVAL; \
|
|
|
|
var = new; \
|
|
|
|
start; \
|
|
|
|
return end-buf; \
|
|
|
|
} \
|
|
|
|
static SYSDEV_ATTR(name, 0644, show_ ## name, set_ ## name);
|
|
|
|
|
2007-02-13 05:26:23 -07:00
|
|
|
/* TBD should generate these dynamically based on number of available banks */
|
2005-04-16 15:20:36 -07:00
|
|
|
ACCESSOR(bank0ctl,bank[0],mce_restart())
|
|
|
|
ACCESSOR(bank1ctl,bank[1],mce_restart())
|
|
|
|
ACCESSOR(bank2ctl,bank[2],mce_restart())
|
|
|
|
ACCESSOR(bank3ctl,bank[3],mce_restart())
|
|
|
|
ACCESSOR(bank4ctl,bank[4],mce_restart())
|
2006-01-11 14:43:06 -07:00
|
|
|
ACCESSOR(bank5ctl,bank[5],mce_restart())
|
2007-02-13 05:26:23 -07:00
|
|
|
|
|
|
|
static ssize_t show_trigger(struct sys_device *s, char *buf)
|
|
|
|
{
|
|
|
|
strcpy(buf, trigger);
|
|
|
|
strcat(buf, "\n");
|
|
|
|
return strlen(trigger) + 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t set_trigger(struct sys_device *s,const char *buf,size_t siz)
|
|
|
|
{
|
|
|
|
char *p;
|
|
|
|
int len;
|
|
|
|
strncpy(trigger, buf, sizeof(trigger));
|
|
|
|
trigger[sizeof(trigger)-1] = 0;
|
|
|
|
len = strlen(trigger);
|
|
|
|
p = strchr(trigger, '\n');
|
|
|
|
if (*p) *p = 0;
|
|
|
|
return len;
|
|
|
|
}
|
|
|
|
|
|
|
|
static SYSDEV_ATTR(trigger, 0644, show_trigger, set_trigger);
|
2005-04-16 15:20:36 -07:00
|
|
|
ACCESSOR(tolerant,tolerant,)
|
|
|
|
ACCESSOR(check_interval,check_interval,mce_restart())
|
2007-02-13 05:26:23 -07:00
|
|
|
static struct sysdev_attribute *mce_attributes[] = {
|
|
|
|
&attr_bank0ctl, &attr_bank1ctl, &attr_bank2ctl,
|
|
|
|
&attr_bank3ctl, &attr_bank4ctl, &attr_bank5ctl,
|
|
|
|
&attr_tolerant, &attr_check_interval, &attr_trigger,
|
|
|
|
NULL
|
|
|
|
};
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2005-07-28 21:15:39 -07:00
|
|
|
/* Per cpu sysdev init. All of the cpus still share the same ctl bank */
|
|
|
|
static __cpuinit int mce_create_device(unsigned int cpu)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
int err;
|
2006-01-11 14:43:06 -07:00
|
|
|
int i;
|
2005-07-28 21:15:39 -07:00
|
|
|
if (!mce_available(&cpu_data[cpu]))
|
|
|
|
return -EIO;
|
|
|
|
|
|
|
|
per_cpu(device_mce,cpu).id = cpu;
|
|
|
|
per_cpu(device_mce,cpu).cls = &mce_sysclass;
|
|
|
|
|
|
|
|
err = sysdev_register(&per_cpu(device_mce,cpu));
|
|
|
|
|
|
|
|
if (!err) {
|
2007-02-13 05:26:23 -07:00
|
|
|
for (i = 0; mce_attributes[i]; i++)
|
2006-01-11 14:43:06 -07:00
|
|
|
sysdev_create_file(&per_cpu(device_mce,cpu),
|
2007-02-13 05:26:23 -07:00
|
|
|
mce_attributes[i]);
|
2005-07-28 21:15:39 -07:00
|
|
|
}
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2006-07-30 03:03:37 -07:00
|
|
|
static void mce_remove_device(unsigned int cpu)
|
2005-07-28 21:15:39 -07:00
|
|
|
{
|
2006-01-11 14:43:06 -07:00
|
|
|
int i;
|
|
|
|
|
2007-02-13 05:26:23 -07:00
|
|
|
for (i = 0; mce_attributes[i]; i++)
|
2006-01-11 14:43:06 -07:00
|
|
|
sysdev_remove_file(&per_cpu(device_mce,cpu),
|
2007-02-13 05:26:23 -07:00
|
|
|
mce_attributes[i]);
|
2005-07-28 21:15:39 -07:00
|
|
|
sysdev_unregister(&per_cpu(device_mce,cpu));
|
2006-12-06 18:14:12 -07:00
|
|
|
memset(&per_cpu(device_mce, cpu).kobj, 0, sizeof(struct kobject));
|
2005-07-28 21:15:39 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Get notified when a cpu comes on/off. Be hotplug friendly. */
|
2006-07-30 03:03:37 -07:00
|
|
|
static int
|
2005-07-28 21:15:39 -07:00
|
|
|
mce_cpu_callback(struct notifier_block *nfb, unsigned long action, void *hcpu)
|
|
|
|
{
|
|
|
|
unsigned int cpu = (unsigned long)hcpu;
|
|
|
|
|
|
|
|
switch (action) {
|
|
|
|
case CPU_ONLINE:
|
2007-05-09 02:35:10 -07:00
|
|
|
case CPU_ONLINE_FROZEN:
|
2005-07-28 21:15:39 -07:00
|
|
|
mce_create_device(cpu);
|
|
|
|
break;
|
|
|
|
case CPU_DEAD:
|
2007-05-09 02:35:10 -07:00
|
|
|
case CPU_DEAD_FROZEN:
|
2005-07-28 21:15:39 -07:00
|
|
|
mce_remove_device(cpu);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return NOTIFY_OK;
|
|
|
|
}
|
|
|
|
|
2006-07-30 03:03:37 -07:00
|
|
|
static struct notifier_block mce_cpu_notifier = {
|
2005-07-28 21:15:39 -07:00
|
|
|
.notifier_call = mce_cpu_callback,
|
|
|
|
};
|
|
|
|
|
|
|
|
static __init int mce_init_device(void)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
int i = 0;
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
if (!mce_available(&boot_cpu_data))
|
|
|
|
return -EIO;
|
|
|
|
err = sysdev_class_register(&mce_sysclass);
|
2005-07-28 21:15:39 -07:00
|
|
|
|
|
|
|
for_each_online_cpu(i) {
|
|
|
|
mce_create_device(i);
|
|
|
|
}
|
|
|
|
|
2006-07-30 03:03:37 -07:00
|
|
|
register_hotcpu_notifier(&mce_cpu_notifier);
|
2005-04-16 15:20:36 -07:00
|
|
|
misc_register(&mce_log_device);
|
|
|
|
return err;
|
|
|
|
}
|
2005-07-28 21:15:39 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
device_initcall(mce_init_device);
|