btintel_pcie: -EBUSY from PM callbacks aborts system-wide hibernate/suspend

btintel_pcie: -EBUSY from PM callbacks aborts system-wide hibernate/suspend

[Marvin Göpfert]

# btintel_pcie: -EBUSY from PM callbacks aborts system-wide 
hibernate/suspend

## Summary

On an Intel BE201 (`8086:a876`, PCI `0000:00:14.7`) the `btintel_pcie` 
driver
intermittently returns `-EBUSY` from its PM callbacks. Because the callback
fails, the kernel aborts the *entire* sleep transition and rolls back — 
after
the hibernation image has already been written. The machine silently stays
powered on. For a laptop this is a real hazard: closing the lid appears 
to do
nothing and the machine keeps running in a bag.

The proximate cause is visible in the log: the driver times out three times
waiting for the "alive interrupt" for D3 entry, then gives up.

## Hardware / software

| | |
|---|---|
| Device | Intel Corporation `8086:a876` (rev 10), subsystem `8086:000e` |
| PCI slot | `0000:00:14.7` |
| Driver | `btintel_pcie` |
| Firmware | `intel/ibt-0190-0291-pci.sfi`, Firmware Version 107-8.26 |
| firmware pkg | `linux-firmware-intel-wireless 
20260319.git217ca6e4-0ubuntu2.1` |
| Kernel | `7.0.0-1011-oem` (Ubuntu 26.04.1 LTS) |
| Machine | Dell Pro 14 Plus PB14250, BIOS 2.16.0 (2026-08-03) |

## Steps to reproduce

1. Boot with Bluetooth enabled and the controller in use.
2. `systemctl hibernate` (also reproducible via `systemctl suspend`).
3. Observe that the hibernation image is written completely, then the
    transition is rolled back and the system returns to a running state.

Not deterministic: the same kernel and firmware succeed on many attempts. It
correlates with the controller already having logged `Controller in error
state`, which on this machine happens frequently at driver init.

## Actual behaviour

```
kernel: PM: Image saving done
kernel: Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D3 
entry, retry count 0
kernel: Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D3 
entry, retry count 1
kernel: Bluetooth: hci0: Timeout (200 ms) on alive interrupt for D3 
entry, retry count 2
kernel: btintel_pcie 0000:00:14.7: PM: pci_pm_poweroff(): 
btintel_pcie_hibernate [btintel_pcie] returns -16
kernel: btintel_pcie 0000:00:14.7: PM: dpm_run_callback(): 
pci_pm_poweroff returns -16
kernel: btintel_pcie 0000:00:14.7: PM: failed to hibernate async: error -16
kernel: PM: hibernation: Wakeup event detected during hibernation, 
rolling back.
kernel: PM: hibernation: hibernation exit
```

The same `-EBUSY` was also observed from `pci_pm_suspend()`
(`btintel_pcie_suspend`) and `pci_pm_freeze()` (`btintel_pcie_freeze`) on
2026-08-23, i.e. plain suspend is affected in the same way. Those journal
entries have since rotated out; the hibernate case above is from 2026-08-30.

## Expected behaviour

A Bluetooth controller that cannot reach D3 should not veto a system-wide
sleep transition. Either the driver should recover the controller (it 
already
has a reset path) or force it down and return success, so the transition can
proceed.

## Additional observation: rfkill makes it worse

Soft-blocking the controller before sleep (`rfkill block bluetooth`) as a
gentler alternative to unloading the module does **not** help — and 
appears to
trigger the failure. Immediately after the block, and immediately before the
`-EBUSY`:

```
kernel: btintel_pcie 0000:00:14.7: reset done
kernel: Bluetooth: hci0: Controller in error state
kernel: Bluetooth: hci0: Intel Soft Reset failed (-62)
kernel: Bluetooth: hci0: Controller in error state
kernel: Bluetooth: hci0: Intel Soft Reset failed (-62)
kernel: btintel_pcie 0000:00:14.7: PM: pci_pm_poweroff(): 
btintel_pcie_hibernate returns -16
```

So the rfkill-induced reset is one way to put the controller into the error
state that then blocks the PM transition.

## Related instability at init

The controller frequently fails to come up at boot on this machine, 
requiring
one to three `modprobe -r btintel_pcie && modprobe btintel_pcie` cycles:

```
kernel: Bluetooth: hci0: Firmware loaded in 776747 usecs
kernel: Bluetooth: hci0: Controller in error state
kernel: Bluetooth: hci0: Timeout (3000 ms) on alive interrupt, alive 
context: intel_reset1
kernel: Bluetooth: hci0: Failed to send frame (-62)
kernel: Bluetooth: hci0: Intel Soft Reset failed (-62)
```

Firmware load time correlates with the outcome: successful inits load in
50–110 ms, failing ones in 540–780 ms. Occasionally no number of module
reloads recovers it and a full power-cycle (AC removed, power button held
~20 s) is required. This may or may not share a root cause with the PM 
issue,
but it is the state in which the PM failure occurs.

## Workaround in use

Unload the module before sleeping and reload afterwards, via
`/usr/lib/systemd/system-sleep/`:

```sh
case "$1" in
     pre)  modprobe -r btintel_pcie ;;
     post) modprobe btintel_pcie ;;
esac
```

This is reliable, but forces a firmware re-download on every sleep cycle,
which in turn is the main opportunity for the init failure described above.