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

Sourabh Jain
2026-04-14T10:29:54Z

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@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 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@gmail.com
>
>
> Adriano
>
>