summaryrefslogtreecommitdiff
path: root/virt
diff options
context:
space:
mode:
authorOliver O'Halloran <oohall@gmail.com>2019-09-03 20:16:03 +1000
committerMichael Ellerman <mpe@ellerman.id.au>2019-09-05 14:22:39 +1000
commit22cda7c1680c1ddfe941adae45e7e7ef52d0e411 (patch)
treee7210064e06d21063924c705819ee5d9f7cd9ffb /virt
parentaeff27c121ba7397c21a47c749e2b5be07f48c17 (diff)
powerpc/eeh: Add debugfs interface to run an EEH check
Detecting an frozen EEH PE usually occurs when an MMIO load returns a 0xFFs response. When performing EEH testing using the EEH error injection feature available on some platforms there is no simple way to kick-off the kernel's recovery process since any accesses from userspace (usually /dev/mem) will bypass the MMIO helpers in the kernel which check if a 0xFF response is due to an EEH freeze or not. If a device contains a 0xFF byte in it's config space it's possible to trigger the recovery process via config space read from userspace, but this is not a reliable method. If a driver is bound to the device an in use it will frequently trigger the MMIO check, but this is also inconsistent. To solve these problems this patch adds a debugfs file called "eeh_dev_check" which accepts a <domain>:<bus>:<dev>.<fn> string and runs eeh_dev_check_failure() on it. This is the same check that's done when the kernel gets a 0xFF result from an config or MMIO read with the added benifit that it can be reliably triggered from userspace. Signed-off-by: Oliver O'Halloran <oohall@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20190903101605.2890-13-oohall@gmail.com
Diffstat (limited to 'virt')
0 files changed, 0 insertions, 0 deletions