Re: [PATCH] powerpc/fadump: Add timeout to RTAS busy-wait loops

[Sourabh Jain]

On 14/04/26 03:07, litaliano00 wrote:
> On Mon, Apr 13, 2026, 15: 50 Sourabh Jain 
> <sourabhjain@ linux. ibm. com> wrote: > What is the rationale behind 
> choosing a 60-second limit? The 60-second value was chosen somewhat 
> arbitrarily. Looking at rtas_busy_delay_time(), the maximum
>
> On Mon, Apr 13, 2026, 15:50 Sourabh Jain <sourabhjain@xxxxxxxxxxxxx> 
> wrote:
>
>     > What is the rationale behind choosing a 60-second limit? 
>
>
>     The 60-second value was chosen somewhat arbitrarily. Looking at
>
>     rtas_busy_delay_time(), the maximum single delay returned is 100000ms
>
>     (status 9905). In practice, legitimate busy delays are expected to be
>
>     much shorter. I was following the spirit of rtas-rtc.c which uses a
>
>     5-second limit for simpler operations; fadump is a heavier firmware
>
>     operation, so I went higher. I am open to suggestions on a more
>
>     principled value.


phyp/RTAS is a black box to me, so it is hard to conclude
what happens during fadump register/unregister/invalidate.
However, based on QEMU's fadump implementation, all three
operations do not seem very complex.

That said, I am OK with a 60 sec timeout.

I would also recommend adding pr_debug logs when the wait
time is hit. It might help debug cases where the kernel
reaches the 60 sec limit especially during boot.

- Sourabh Jain

>     > Would it make sense to introduce a helper function to wrap the
>
>     > rtas_call, along with handling the wait time and timeout?
>
>
>     Absolutely, I will introduce a helper in v2. The three sites are
>
>     indeed identical except for the FADUMP_REGISTER/UNREGISTER/INVALIDATE
>
>     argument and the struct pointer/size. I will factor out the common
>
>     busy-wait loop into a static helper.
>
>
>     Will send v2 shortly from my new email adri.vero.dev@xxxxxxxxx
>
>
>     Adriano