Re: [PATCH] powerpc/rtas: Introduce rtas_get_sensor_nonblocking() for pci hotplug driver.

[Nathan Lynch <nathanl@linux.ibm.com>]

Mahesh J Salgaonkar <mahesh@linux.ibm.com> writes:

> On 2021-11-29 22:53:41 Mon, Nathan Lynch wrote:
>> Mahesh Salgaonkar <mahesh@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.