btintel_pcie: controller left dead after a boot-stage error, 1 in 12 warm reboots

[Sergey Lebedev]

Roughly one warm reboot in twelve, the Bluetooth controller on a Surface Pro 11
comes up dead with BD Address 00:00:00:00:00:00, and stays that way until
btintel_pcie is reloaded by hand. This is a report rather than a patch: the
trigger looks like a device-side fault, but the driver has recovery machinery
it does not reach for here, and that part looks addressable.

I could not find this reported anywhere. Searching lore for "Unsupported cnvi"
returns only patches carrying the string in the driver source.

Hardware: Microsoft Surface Pro for Business 11th Edition with Intel, Core Ultra
7 268V, UEFI 17.105.143. Controller firmware 2026.8 build 113003, bootloader
2023.33 build 45995, unchanged throughout. Ubuntu 26.04, kernel 7.0.0-30.

What differs between a good and a bad boot
------------------------------------------

Twelve consecutive warm reboots, one kernel, one firmware, nothing changed
between them, thirty minutes end to end. One failed. The second-stage firmware
load from each, trimmed to the lines that differ:

  failing boot                          every healthy boot

  Found device firmware: ...-pci.sfi    Found device firmware: ...-pci.sfi
  Boot Address: 0x10000800              Boot Address: 0x10000800
  Firmware Version: 107-8.26            Firmware Version: 107-8.26
  Received gp1 mailbox interrupt        Waiting for firmware download to complete
  Waiting for firmware download to ...  Firmware loaded in 645371 usecs
  Firmware loaded in 685555 usecs       Received gp1 mailbox interrupt
  Received gp1 mailbox interrupt        Waiting for device to boot
  Controller in error state

One extra gp1 mailbox interrupt, arriving before the download rather than after
it. Same firmware file, same boot address, same version, download times within
10 % of each other. Counted across the series, every healthy boot has exactly
one gp1 interrupt and no error state; the failing boot has six and three, the
extra ones being the driver's own retries.

After that it fails the way a driver fails when its handshake is out of step:

  Timeout (3000 ms) on alive interrupt, alive context: intel_reset1
  Failed to send frame (-62)
  Intel Soft Reset failed (-62)
  Firmware download retry count: 1

three times over, and the controller is left with a zero address.
"Unsupported cnvi 0x00000000", which is the string one would search for, is a
consequence several steps down and not the fault itself.

The part that looks like a driver question
------------------------------------------

btintel_pcie_msix_gp0_handler() detects the condition and stops there:

	if (btintel_pcie_in_error(data)) {
		bt_dev_err(data->hdev, "Controller in error state");
		btintel_pcie_dump_debug_registers(data->hdev);
		return;
	}

while btintel_pcie_pci_resume() reaches the same predicate and recovers from it:

	if (btintel_pcie_in_error(data) || btintel_pcie_in_device_halt(data)) {
		bt_dev_err(data->hdev, "Controller in error state for D0 entry");
		...
		btintel_pcie_reset(data->hdev);
	}

Reloading the module recovers the controller every time, which suggests the
device is not permanently wedged - only that nothing tries again. Whether the
boot path should call btintel_pcie_reset() the way the resume path does is a
question for people who know the hardware; from outside it is the obvious thing
to ask.

Rates
-----

  retained journal, to 2026-08-30                     16 failures / 50 boots
  controlled warm reboots, 2026-08-31, after a
  firmware update to UEFI 17.105.143                   1 failure  / 12 boots

The earlier 16 were clustered - 15 inside one 24-hour window - which is why I
waited for a controlled series before writing. Note also that it is not
cold-boot-specific: 12 of those 16 followed a warm reboot.

I can test patches on this machine and reproduce on demand; twelve reboots take
half an hour. Full logs of the series and both boot types available on request.

Thanks,
Sergey