Mahesh J Salgaonkar <mah...@linux.ibm.com> writes: > On 2021-11-29 22:53:41 Mon, Nathan Lynch wrote: >> Mahesh Salgaonkar <mah...@linux.ibm.com> writes: >> > When certain PHB HW failure causes phyp to recover PHB, it marks the PE >> > state as temporarily unavailable until recovery is complete. This also >> > triggers an EEH handler in Linux which needs to notify drivers, and perform >> > recovery. But before notifying the driver about the pci error it uses >> > get_adapter_state()->get-sesnor-state() operation of the hotplug_slot to >> > determine if the slot contains a device or not. if the slot is empty, the >> > recovery is skipped entirely. >> > >> > However on certain PHB failures, the rtas call get-sesnor-state() returns >> > extended busy error (9902) until PHB is recovered by phyp. Once PHB is >> > recovered, the get-sensor-state() returns success with correct presence >> > status. The rtas call interface rtas_get_sensor() loops over the rtas call >> > on extended delay return code (9902) until the return value is either >> > success (0) or error (-1). This causes the EEH handler to get stuck for ~6 >> > seconds before it could notify that the pci error has been detected and >> > stop any active operations. >> >> I am curious whether you see any difference with "powerpc/rtas: >> rtas_busy_delay() improvements" which was recently applied. It will >> cause the the calling task to sleep in response to a 990x status instead >> of immediately retrying: > > If it is still sleeping it may not help, however I will give a try.
Thanks. My thought is that with the old behavior of rtas_busy_delay(), the repeated retries (potentially hundreds or thousands of get-sensor-state calls) that occur before finally sleeping may be prolonging the ongoing PHB recovery.
