Linux 7.3 caps EFI runtime calls at 120 seconds so one bad firmware call no longer freezes the whole server
A hung EFI runtime service call used to wedge an entire host: the kworker stayed trapped inside firmware while holding efi_runtime_lock until someone rebooted the machine. Linux 7.3 adds a 120-second timeout that declares the firmware ’wedged’ and turns a silent freeze into an explicit dmesg verdict.
June 16, 2026. Breno Leitao, a Debian developer and kernel engineer at Meta, posts v3 of a patch series to bound EFI runtime calls. August 23, 2026. The EFI updates are merged into the in-development Linux 7.3 kernel. August 16, 2026. Linux 7.2 ships with its own I/O gains — but without this safeguard.
The change fits in one sentence: when an EFI runtime call gets stuck inside firmware, the kernel used to wait forever. Now it waits 120 seconds, then declares the firmware “wedged”. Behind that single word sit weeks of debugging on servers that froze with no trace other than a workqueue lockup message.
One lock that freezes everything
To grasp the fix, follow the exact path of an EFI runtime call. These services — NVRAM reads and writes, set_wakeup_time, ACPI PRM handlers, efivarfs access — all funnel through a dedicated kworker, efi_rts_wq. When one of those calls enters firmware and never returns, the kworker stays trapped inside the firmware call.
This is no ordinary stall. The kworker cannot be cancelled, and the caller holds efi_runtime_lock for the entire duration of the block. The result is mechanical: every subsequent EFI runtime caller — efivarfs, NVRAM writes, set_wakeup_time, ACPI PRM handlers — queues up on the semaphore and waits, uninterruptibly, until reboot.
Leitao describes the symptom in his cover letter: the PC and LR point into the runtime services’ firmware memory; firmware never returned; the worker stayed stuck through workqueue lockup reports at 127 s, 157 s, and 188 s, until external monitoring finally rebooted the host. For an operator, nothing points at firmware: the same symptom could be blamed on dozens of unrelated stalls.
The firmware is at fault, not the kernel
The patch does not fix the firmware bug — that is the vendor’s territory. What it changes is the blast radius. Leitao’s series adds a timeout to runtime-service completions: past 120 seconds, the kernel stops letting the call hang indefinitely.
The threshold is not arbitrary. It is deliberately longer than any plausible legitimate call into EFI runtime services. A call that exceeds 120 seconds is therefore, by construction, a call firmware never returned — not a merely slow one. The distinction matters: it avoids declaring a firmware “wedged” when it is simply busy on a long but valid operation.
What is at stake goes beyond one isolated server. At fleet scale, a freeze wrongly attributed to some other subsystem — storage, networking, the scheduler — triggers expensive investigations in every direction except the right one. The new dmesg signal inverts the logic: instead of a stalled task mystery, you get an unambiguous verdict — “EFI firmware is at fault”. That is the kind of message that points an on-call engineer at the right vendor in seconds.
Where the need came from: an NVIDIA Grace server
The concrete trigger was an incident on an NVIDIA Grace server. Recent Arm hardware, especially the platforms aimed at dense compute, leans on firmware for runtime services far more than a typical x86 box. When that firmware misbehaves, the kernel has no way to regain control without a safeguard like this one.
Meta as the proving ground is no accident. The company runs server fleets at a scale where a silent freeze that strikes once every few months per machine becomes a constant stream of incidents. That is exactly the context the cover letter calls “fleet scale”: at that volume, a signal that separates firmware from every other cause is worth its weight in engineering hours.
The fix travelled through the kernel’s EFI branch, merged on August 23, 2026 into the 7.3 cycle. It sits alongside other work in the same cycle — stack randomization cleanup, new AES APIs, broader DRM support — but it is one of the few whose value is purely operational rather than functional.
What it changes for an SRE
The immediate benefit is a smaller blast radius for a firmware bug. Before, one stuck call took the whole of user space down with it; now it costs at most a timeout and produces a clean log line. A host that reboots on its own becomes a documented firmware incident rather than a mystery.
The second benefit is detection. The explicit dmesg message lets you automate an alert: instead of waiting for external monitoring to reboot the box after 127 s, 157 s, or 188 s of silence, you can correlate the “firmware wedged” verdict with the matching vendor ticket, and count occurrences per platform model.
The third benefit is subtler: diagnostic precision cuts mean time to resolution. When an on-call engineer knows up front that firmware is at fault, they do not spend the night ruling out storage, networking, or the scheduler. The timeout turns a generic freeze into an addressable problem.
Why runtime services are a blind spot
EFI services split into two families. Boot services exist only during startup, then the kernel takes over and they disappear. Runtime services stay active for the entire life of the system: NVRAM reads, wake-time configuration, and some ACPI handlers all travel through them. It is precisely because they stay active that a firmware bug at this point is so dangerous — and so hard to fix on the kernel side.
On most servers, these calls return in microseconds and go unnoticed. The grey zone only reveals itself when firmware stalls: the kernel can neither cancel the call nor regain control, and cannot even tell a slow call from a dead one. The 120-second timeout closes exactly that ambiguity, choosing a threshold no legitimate call should ever reach.
Spotting the problem before it costs a reboot is one command:
dmesg -T | grep -iE "efi.*(wedged|timeout|fault)"Across a fleet, that filter becomes an alert: an “EFI firmware is at fault” occurrence should open a vendor ticket, not a kernel investigation. The incident finally becomes categorizable, and that is the whole point of the fix for an SRE. In effect, the kernel now behaves like a watchdog: it grants firmware a generous but finite window to return, and it reports clearly when that window is exceeded.
Verdict
If you run Arm servers, or fleets where silent freezes recur with no obvious cause, watch for Linux 7.3 and capture these verdicts from dmesg. The safeguard does not fix your firmware — but it turns an opaque outage into an actionable signal, which is already half the distance to a closed vendor ticket.
If you are on older or stable hardware, the change is transparent: the 120-second threshold sits above any legitimate call, so nothing shifts as long as your firmware behaves. You simply gain a safety net you hoped you would never need.
The lesson reaches beyond EFI. A kernel that waits indefinitely on an external component — firmware, driver, device — hands that component control over its own availability. Bounding the wait is how you take that control back from a system that seemed to freeze for no reason.