mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-28 11:18:45 +07:00
f2dd80ecca
All unrecovered machine check errors on PowerNV should cause an
immediate panic. There are 2 reasons that this is the right policy:
it's not safe to continue, and we're already trying to reboot.
Firstly, if we go through the recovery process and do not successfully
recover, we can't be sure about the state of the machine, and it is
not safe to recover and proceed.
Linux knows about the following sources of Machine Check Errors:
- Uncorrectable Errors (UE)
- Effective - Real Address Translation (ERAT)
- Segment Lookaside Buffer (SLB)
- Translation Lookaside Buffer (TLB)
- Unknown/Unrecognised
In the SLB, TLB and ERAT cases, we can further categorise these as
parity errors, multihit errors or unknown/unrecognised.
We can handle SLB errors by flushing and reloading the SLB. We can
handle TLB and ERAT multihit errors by flushing the TLB. (It appears
we may not handle TLB and ERAT parity errors: I will investigate
further and send a followup patch if appropriate.)
This leaves us with uncorrectable errors. Uncorrectable errors are
usually the result of ECC memory detecting an error that it cannot
correct, but they also crop up in the context of PCI cards failing
during DMA writes, and during CAPI error events.
There are several types of UE, and there are 3 places a UE can occur:
Skiboot, the kernel, and userspace. For Skiboot errors, we have the
facility to make some recoverable. For userspace, we can simply kill
(SIGBUS) the affected process. We have no meaningful way to deal with
UEs in kernel space or in unrecoverable sections of Skiboot.
Currently, these unrecovered UEs fall through to
machine_check_expection() in traps.c, which calls die(), which OOPSes
and sends SIGBUS to the process. This sometimes allows us to stumble
onwards. For example we've seen UEs kill the kernel eehd and
khugepaged. However, the process killed could have held a lock, or it
could have been a more important process, etc: we can no longer make
any assertions about the state of the machine. Similarly if we see a
UE in skiboot (and again we've seen this happen), we're not in a
position where we can make any assertions about the state of the
machine.
Likewise, for unknown or unrecognised errors, we're not able to say
anything about the state of the machine.
Therefore, if we have an unrecovered MCE, the most appropriate thing
to do is to panic.
The second reason is that since
|
||
|---|---|---|
| .. | ||
| eeh-powernv.c | ||
| idle.c | ||
| Kconfig | ||
| Makefile | ||
| opal-async.c | ||
| opal-dump.c | ||
| opal-elog.c | ||
| opal-flash.c | ||
| opal-hmi.c | ||
| opal-irqchip.c | ||
| opal-lpc.c | ||
| opal-memory-errors.c | ||
| opal-msglog.c | ||
| opal-nvram.c | ||
| opal-power.c | ||
| opal-prd.c | ||
| opal-rtc.c | ||
| opal-sensor.c | ||
| opal-sysparam.c | ||
| opal-tracepoints.c | ||
| opal-wrappers.S | ||
| opal-xscom.c | ||
| opal.c | ||
| pci-ioda.c | ||
| pci-p5ioc2.c | ||
| pci.c | ||
| pci.h | ||
| powernv.h | ||
| rng.c | ||
| setup.c | ||
| smp.c | ||
| subcore-asm.S | ||
| subcore.c | ||
| subcore.h | ||