aboutsummaryrefslogtreecommitdiffstats
path: root/arch/powerpc/sysdev/xive/native.c
diff options
context:
space:
mode:
authorMichael Ellerman <[email protected]>2018-06-13 13:24:14 +0000
committerMichael Ellerman <[email protected]>2018-07-12 11:08:10 +0000
commit54dbcfc211f15586c57d27492f938eb4df964257 (patch)
treee96c32f125e4e30e4644aa432b6f15c55806244f /arch/powerpc/sysdev/xive/native.c
parentpowerpc: Remove Power8 DD1 from cputable (diff)
downloadkernel-54dbcfc211f15586c57d27492f938eb4df964257.tar.gz
kernel-54dbcfc211f15586c57d27492f938eb4df964257.zip
powerpc/64s: Report SLB multi-hit rather than parity error
When we take an SLB multi-hit on bare metal, we see both the multi-hit and parity error bits set in DSISR. The user manuals indicates this is expected to always happen on Power8, whereas on Power9 it says a multi-hit will "usually" also cause a parity error. We decide what to do based on the various error tables in mce_power.c, and because we process them in order and only report the first, we currently always report a parity error but not the multi-hit, eg: Severe Machine check interrupt [Recovered] Initiator: CPU Error type: SLB [Parity] Effective address: c000000ffffd4300 Although this is correct, it leaves the user wondering why they got a parity error. It would be clearer instead if we reported the multi-hit because that is more likely to be simply a software bug, whereas a true parity error is possibly an indication of a bad core. We can do that simply by reordering the error tables so that multi-hit appears before parity. That doesn't affect the error recovery at all, because we flush the SLB either way. Signed-off-by: Michael Ellerman <[email protected]> Reviewed-by: Nicholas Piggin <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
Diffstat (limited to 'arch/powerpc/sysdev/xive/native.c')
0 files changed, 0 insertions, 0 deletions