firecracker-microvm/firecracker · error
i8042 lock was poisoned
Error message
i8042 lock was poisoned
What it means
Panic in `Vmm::send_ctrl_alt_del` (lib.rs:494, x86_64 only): the i8042 (keyboard controller) device mutex is acquired with `.lock().expect("i8042 lock was poisoned")` before `trigger_ctrl_alt_del()`. Poisoned means another thread panicked while holding the i8042 lock; this API call then aborts the VMM instead of returning a VmmError (the function is already fallible — NotSupported, I8042Error).
Source
Thrown at src/vmm/src/lib.rs:494
let kvm_vm = self
.vm
.as_kvm()
.ok_or_else(|| VmmError::NotSupportedOnVmType(self.vm.type_name()))?;
kvm_vm.pause_vcpus()?;
self.instance_info.state = VmState::Paused;
Ok(())
}
/// Injects CTRL+ALT+DEL keystroke combo in the i8042 device.
#[cfg(target_arch = "x86_64")]
pub fn send_ctrl_alt_del(&mut self) -> Result<(), VmmError> {
self.device_manager
.legacy_devices
.as_ref()
.ok_or(VmmError::NotSupported)?
.i8042
.lock()
.expect("i8042 lock was poisoned")
.trigger_ctrl_alt_del()
.map_err(VmmError::I8042Error)
}
/// Saves the state of a paused Microvm.
pub fn save_state(&mut self, vm_info: &VmInfo) -> Result<MicrovmState, MicrovmStateError> {
self.check_unsnapshottable_devices()?;
// We need to save device state before saving KVM state.
// Some devices, (at the time of writing this comment block device with async engine)
// might modify the VirtIO transport and send an interrupt to the guest. If we save KVM
// state before we save device state, that interrupt will never be delivered to the guest
// upon resuming from the snapshot.
let device_states = self.device_manager.save();
let kvm_vm = self
.vm
.as_kvm()
.ok_or_else(|| MicrovmStateError::NotAllowed("save_state requires KVM".into()))?;View on GitHub (pinned to 0a745def42)
Solutions
- Locate the original panic in the logs (first occurrence, before this expect) and fix it — poisoning is only a symptom
- Map the poisoning to a VmmError instead of panicking: `.lock().map_err(|_| VmmError::I8042Poisoned)` or unwrap_or_else(into_inner) if reset-on-poison is acceptable
- Review i8042 lock scopes: never hold the lock across infallible-looking code that can panic (e.g. indexing, unwraps in event handlers)
Example fix
// before
self.device_manager
.legacy_devices
.as_ref()
.ok_or(VmmError::NotSupported)?
.i8042
.lock()
.expect("i8042 lock was poisoned")
.trigger_ctrl_alt_del()
.map_err(VmmError::I8042Error)
// after
self.device_manager
.legacy_devices
.as_ref()
.ok_or(VmmError::NotSupported)?
.i8042
.lock()
.unwrap_or_else(|poisoned| poisoned.into_inner())
.trigger_ctrl_alt_del()
.map_err(VmmError::I8042Error) Defensive patterns
Strategy: fallback
Validate before calling
// Nothing prevents the panic at the call site; instead check service health before sending CAD
if i8042_is_healthy() {
vmm.send_ctrl_alt_del()?;
} else {
// fall back to a different reset mechanism (e.g. action_type REBOOT if available)
} Try / catch
// Recover the lock since trigger_ctrl_alt_del only needs the input state
let i8042 = self.device_manager
.legacy_devices
.as_ref()
.ok_or(VmmError::NotSupported)?
.i8042
.lock()
.unwrap_or_else(|p| p.into_inner());
i8042.trigger_ctrl_alt_del().map_err(VmmError::I8042Error) Prevention
- Keep i8042 lock critical sections panic-free (no unwraps/indexing while locked)
- React to the FIRST panic that poisons it — this expect is downstream noise
- Have a non-keyboard reset fallback (VM reboot action) for CAD delivery failures
When it happens
Trigger: Calling the SendCtrlAltDel API endpoint after an earlier panic in whatever thread drives the i8042 device (input event handling / KVM exit handling holding the lock at panic time).
Common situations: Attempting a keyboard-reset style reboot of the guest after an input-device thread crashed; restoring/reusing a long-running firecracker process where the i8042 lock got poisoned by an unrelated panic while the legacy device was locked.
Related errors
- error unlocking vmm
- Poisoned lock
- GDB requires KVM
- Error getting initial gdb event
- Error converting cpu id to Tid
AI-assisted analysis of firecracker-microvm/firecracker@0a745def42 (2026-08-19).
Data as JSON: /api/errors/5c13d9e831288a6e.
Report an issue: GitHub.