[Bug 222105] New: btintel_pcie (8086:e476, Panther Lake CNVi): BLE device using a Resolvable Private Address fails to reconnect after suspend/idle and requires re-pairing

[Bug 222105] New: btintel_pcie (8086:e476, Panther Lake CNVi): BLE device using a Resolvable Private Address fails to reconnect after suspend/idle and requires re-pairing

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=222105

            Bug ID: 222105
           Summary: btintel_pcie (8086:e476, Panther Lake CNVi): BLE
                    device using a Resolvable Private Address fails to
                    reconnect after suspend/idle and requires re-pairing
           Product: Drivers
           Version: 2.5
          Hardware: Intel
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Bluetooth
          Assignee: linux-bluetooth@vger.kernel.org
          Reporter: przemekm83@interia.pl
        Regression: No

Created attachment 311033
  --> https://bugzilla.kernel.org/attachment.cgi?id=311033&action=edit
dmesg dump

ENVIRONMENT
===========
Distro:      Fedora 44
Kernel:      7.2.8-200.fc44.x86_64
Driver:      btintel_pcie
Controller:  00:14.7 Bluetooth [0d11]: Intel Corporation Core Ultra Processors
             (Series 3) CNVi Bluetooth [8086:e476] (rev 01)
Firmware:    intel/ibt-00a0-01a1-pci.sfi, firmware version 214-29.26
Peripheral:  Logitech MX Anywhere 3S (BLE mouse), modalias usb:v046DpB037d0003

DESCRIPTION
===========
A paired BLE mouse that has been working stops reconnecting after the laptop
suspends (s2idle) or after an idle period. The device does not reappear in
scans, and `bluetoothctl connect <bonded-MAC>` hangs with no result. Re-pairing
fixes it, but the problem recurs. The same mouse reconnects flawlessly on
macOS.

The device uses a Resolvable Private Address (RPA). The stored bond contains an
IdentityResolvingKey:

    AddressType=static
    [IdentityResolvingKey]
    Key=...

Observed behaviour:
- After suspend/resume, the mouse is invisible to `bluetoothctl scan on`, while
  other BLE devices in range ARE seen (so the radio receive path works).
- The mouse's rotating RPA is not resolved back to its stable identity, so the
  host treats it as a new device and the existing bond is effectively lost.
- On re-pairing, the device identity address is regenerated by the peripheral
  (last byte increments: DD:28:F7:5C:A0:49 -> DD:28:F7:5C:A0:4A). This is a
  consequence of the forced re-pair, not the root cause.
- No clean disconnect is logged in the kernel; the link drops silently.

REGRESSION NOTE
===============
The problem started around 2026-10-06/07. The device had been stable for ~a
month. Kernel 7.2.8 was installed on 2026-10-03 and is the most recent relevant
update (the 7.2.8 changelog and recent linux-bluetooth patches touch RPA
resolution and btintel_pcie). Not yet bisected against 7.2.7.

REPRODUCTION
============
1. Pair a BLE device that uses RPA (e.g. Logitech MX Anywhere 3S).
2. Suspend (s2idle) or leave the device idle until it deep-sleeps.
3. Resume / wake the device.
4. The device does not reconnect; it is absent from `bluetoothctl devices`
   (or a new address appears) and re-pairing is required.

RELEVANT LOG LINES
==================
Bluetooth: hci0: Found device firmware: intel/ibt-00a0-01a1-pci.sfi
Bluetooth: hci0: Firmware Version: 214-29.26
Bluetooth: hci0: Failed to send Intel_Write_DDC (-95)

RELATED EXISTING BUGS
=====================
- 221346  btintel_pcie (8086:e476) hang in shutdown path
- 221481  btintel_pcie: suspend fails with -EBUSY on Intel Lunar Lake (s2idle)
- 220419  Bluetooth stops working on Intel BE201 (btintel_pcie)

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.