![\"LINUX](\"https:\/\/www.phoronix.com\/assets\/categories\/linuxkernel.webp\")
\nThe EFI updates were merged today for the in-development Linux 7.3 kernel. Most notable with the EFI updates is now enforcing a timeout foe EFI runtime service completions rather than potentially hanging indefinitely.<\/p>\n
\nThe EFI updates were merged today for the in-development Linux 7.3 kernel. Most notable with the EFI updates is now enforcing a timeout foe EFI runtime service completions rather than potentially hanging indefinitely.<\/p>\n
A change made to the Linux 7.3 kernel will now set a timeout for EFI runtime service completions rather than potentially hanging indefinitely. If the timeout is exceeded, the firmware will declare wedged. This helps deal with buggy EFI\/firmware on some platforms where it could ultimately end up taking down the rest of the user-space. <\/p>\n
Breno Leitao, Debian developer and kernel engineer at Meta, worked through the patches to provide a timeout on EFI runtime service calls. This came up after hitting the issue on a NVIDIA Grace server. Leitao explained the situation with the patch series<\/a> cover letter:
<\/p>\n “When an EFI runtime service call hangs in firmware, the kworker on efi_rts_wq is stuck inside the firmware call and cannot be cancelled. The kernel currently waits indefinitely on the completion, and the caller holds efi_runtime_lock for the duration, so every subsequent EFI runtime caller (efivarfs, NVRAM writes, set_wakeup_time, ACPI PRM handlers, …) is wedged until reboot. The only externally visible symptom is a “workqueue lockup” message and userspace processes piling up uninterruptibly on the semaphore.
This series doesn’t fix the firmware bug – that’s vendor territory – but it stops one stuck EFI call from taking the rest of userspace down with it, and turns a generic stalled-task mystery into an unambiguous “EFI firmware is at fault” signal in dmesg, which is especially valuable at fleet scale where the same symptom could otherwise be attributed to dozens of unrelated stalls.”<\/p>\n The timeout threshold being set is 120 seconds as longer than “any plausible legitimate call” into the EFI runtime services.<\/p>\n
…
PC and LR are inside EFI runtime services firmware memory; firmware never returned; the worker stayed stuck across the 127s \/ 157s \/ 188s “workqueue lockup” reports until external monitoring eventually rebooted the host.
<\/p>\n