On Fri, 2018-03-23 at 17:33 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2018-03-23 at 16:44 +1100, Michael Neuling wrote:
>
> .../...
>
> > This fixes the problem in the same way the generic PCIe AER code (in
> > drivers/pci/pcie/aer/aerdrv_core.c) does. It makes the EEH code hold
> > the
On Fri, 2018-03-23 at 17:33 +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2018-03-23 at 16:44 +1100, Michael Neuling wrote:
>
> .../...
>
> > This fixes the problem in the same way the generic PCIe AER code
> > (in
> > drivers/pci/pcie/aer/aerdrv_core.c) does. It makes the EEH code
> > hold
>
On Fri, 2018-03-23 at 16:44 +1100, Michael Neuling wrote:
.../...
> This fixes the problem in the same way the generic PCIe AER code (in
> drivers/pci/pcie/aer/aerdrv_core.c) does. It makes the EEH code hold
> the device_lock() before performing the driver EEH callbacks. This
> ensures either
The current EEH callbacks can race with a driver unbind. This
can result in a backtraces like this:
[7.573055] EEH: Frozen PHB#0-PE#1fc detected
[7.573063] EEH: PE location: S09, PHB location: N/A
[7.573069] CPU: 2 PID: 2312 Comm: kworker/u258:3 Not tainted
4.15.6-openpower1 #2
[