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

  1. Locate the original panic in the logs (first occurrence, before this expect) and fix it — poisoning is only a symptom
  2. 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
  3. 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

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


AI-assisted analysis of firecracker-microvm/firecracker@0a745def42 (2026-08-19). Data as JSON: /api/errors/5c13d9e831288a6e. Report an issue: GitHub.