| From foo@baz Mon Jul 3 11:54:22 CEST 2017 |
| From: Gavin Shan <gwshan@linux.vnet.ibm.com> |
| Date: Fri, 6 Jan 2017 10:39:49 +1100 |
| Subject: powerpc/eeh: Enable IO path on permanent error |
| |
| From: Gavin Shan <gwshan@linux.vnet.ibm.com> |
| |
| |
| [ Upstream commit 387bbc974f6adf91aa635090f73434ed10edd915 ] |
| |
| We give up recovery on permanent error, simply shutdown the affected |
| devices and remove them. If the devices can't be put into quiet state, |
| they spew more traffic that is likely to cause another unexpected EEH |
| error. This was observed on "p8dtu2u" machine: |
| |
| 0002:00:00.0 PCI bridge: IBM Device 03dc |
| 0002:01:00.0 Ethernet controller: Intel Corporation \ |
| Ethernet Controller X710/X557-AT 10GBASE-T (rev 02) |
| 0002:01:00.1 Ethernet controller: Intel Corporation \ |
| Ethernet Controller X710/X557-AT 10GBASE-T (rev 02) |
| 0002:01:00.2 Ethernet controller: Intel Corporation \ |
| Ethernet Controller X710/X557-AT 10GBASE-T (rev 02) |
| 0002:01:00.3 Ethernet controller: Intel Corporation \ |
| Ethernet Controller X710/X557-AT 10GBASE-T (rev 02) |
| |
| On P8 PowerNV platform, the IO path is frozen when shutdowning the |
| devices, meaning the memory registers are inaccessible. It is why |
| the devices can't be put into quiet state before removing them. |
| This fixes the issue by enabling IO path prior to putting the devices |
| into quiet state. |
| |
| Reported-by: Pridhiviraj Paidipeddi <ppaidipe@linux.vnet.ibm.com> |
| Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com> |
| Acked-by: Russell Currey <ruscur@russell.cc> |
| Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> |
| Signed-off-by: Sasha Levin <alexander.levin@verizon.com> |
| Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> |
| --- |
| arch/powerpc/kernel/eeh.c | 10 +++++++++- |
| 1 file changed, 9 insertions(+), 1 deletion(-) |
| |
| --- a/arch/powerpc/kernel/eeh.c |
| +++ b/arch/powerpc/kernel/eeh.c |
| @@ -304,9 +304,17 @@ void eeh_slot_error_detail(struct eeh_pe |
| * |
| * For pHyp, we have to enable IO for log retrieval. Otherwise, |
| * 0xFF's is always returned from PCI config space. |
| + * |
| + * When the @severity is EEH_LOG_PERM, the PE is going to be |
| + * removed. Prior to that, the drivers for devices included in |
| + * the PE will be closed. The drivers rely on working IO path |
| + * to bring the devices to quiet state. Otherwise, PCI traffic |
| + * from those devices after they are removed is like to cause |
| + * another unexpected EEH error. |
| */ |
| if (!(pe->type & EEH_PE_PHB)) { |
| - if (eeh_has_flag(EEH_ENABLE_IO_FOR_LOG)) |
| + if (eeh_has_flag(EEH_ENABLE_IO_FOR_LOG) || |
| + severity == EEH_LOG_PERM) |
| eeh_pci_enable(pe, EEH_OPT_THAW_MMIO); |
| |
| /* |
