<div dir="ltr">Hi Ritesh,<br><br>No, I haven't encountered a specific hang on live hardware in production. <br><br>This was a proactive fix that originated from an audit of the RTAS call sites. I noticed the explicit `/* TODO: Add upper time limit for the delay */` comments in rtas-fadump.c that had not yet been implemented. <br><br>When cross-referencing this with other parts of the pSeries code (such as the bounded busy-wait pattern used in rtas-rtc.c), it seemed that adding a timeout is the standard defensive programming approach for these hypervisor calls. <br><br>Since these fadump registration and teardown paths happen during critical boot and state transition phases, a misbehaving hypervisor or firmware anomaly could lead to a hard-to-debug, silent system stall. I implemented the 60-second timeout to resolve the pending TODOs and ensure the kernel remains resilient in those specific edge cases.<br><br>Thanks,<br><div>Adriano</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, Apr 7, 2026 at 6:07 AM Ritesh Harjani <<a href="mailto:ritesh.list@gmail.com">ritesh.list@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Adriano Vero <<a href="mailto:litaliano00.contact@gmail.com" target="_blank">litaliano00.contact@gmail.com</a>> writes:<br>
<br>
> The ibm,configure-kernel-dump RTAS call sites in<br>
> rtas_fadump_register(), rtas_fadump_unregister(), and<br>
> rtas_fadump_invalidate() polled indefinitely while firmware returned<br>
> a busy status. A misbehaving or hung firmware could stall these paths<br>
> forever, blocking fadump registration at boot or preventing clean<br>
> teardown.<br>
<br>
Was there an issue which you encountered? Can you share the details of<br>
the same please?<br>
<br>
<br>
><br>
> Track the accumulated delay in a total_wait counter and bail out with<br>
> -ETIMEDOUT if it reaches RTAS_FADUMP_MAX_WAIT_MS (60 seconds) before<br>
> firmware signals completion. This follows the bounded busy-wait pattern<br>
> used in rtas-rtc.c.<br>
><br>
> Signed-off-by: Adriano Vero <<a href="mailto:litaliano00.contact@gmail.com" target="_blank">litaliano00.contact@gmail.com</a>><br>
</blockquote></div>