Bug Report: Framework 13 - Bluetooth Adapter - Discovery Stops Prematurely

Framework Laptop 13 Linux
1

System Information:

System:
  Kernel: 6.11.4 arch: x86_64 bits: 64 compiler: gcc v: 13.3.0
  Desktop: KDE Plasma v: 6.2.1 tk: Qt v: N/A wm: kwin_wayland dm: SDDM
  Distro: NixOS 24.11 (Vicuna)

Machine:
  Type: Laptop System: Framework product: Laptop (13th Gen Intel Core) v: A4
  serial: <filter>
  Mobo: Framework model: FRANMCCP04 v: A4 serial: <filter> part-nu: FRANDECP04
  UEFI: INSYDE v: 03.05 date: 06/04/2024

Network:
  Device-1: Intel Wi-Fi 6E AX210/AX1675 2x2 [Typhoon Peak] driver: iwlwifi
  v: kernel pcie: speed: 5 GT/s lanes: 1 bus-ID: aa:00.0 chip-ID: 8086:2725
  Device-2: ASIX AX88179 Gigabit Ethernet driver: cdc_ncm type: USB rev: 3.2
  speed: 5 Gb/s lanes: 1 bus-ID: 4-4.1:3 chip-ID: 0b95:1790

Bluetooth:
  Device-1: Intel AX210 Bluetooth driver: btusb v: 0.8 type: USB rev: 2.0
  speed: 12 Mb/s lanes: 1 bus-ID: 1-10:7 chip-ID: 8087:0032
  Report: hciconfig ID: hci0 rfk-id: 0 state: up address: <filter> bt-v: 5.3
  lmp-v: 12 sub-v: 375b

Issue Summary:

The Intel AX210 Bluetooth adapter on a NixOS system stops prematurely during Bluetooth device discovery. After initiating the scan, it stops unexpectedly, removing detected devices and preventing pairing. Multiple adjustments to power management settings have been attempted, but the issue persists. The system is using the latest kernel and firmware from the linux-firmware package, and diagnostics indicate a possible issue with the controller’s state management during discovery.

Details of the Issue:

  • Bluetooth Controller: Intel AX210 Bluetooth Adapter
  • Firmware Version: ibt-0041-0041.sfi (part of linux-firmware package 20241017)
  • Kernel: Latest kernel (6.11.4) in use via linuxPackages_latest in configuration.nix

Observed Behavior:

  1. Discovery Fails Prematurely: Device discovery starts but stops after a short time, and detected devices are removed:

    • Log output: hci0 type 7 discovering off
    • Devices removed: [DEL] Device <MAC>

  2. Pairing Attempts Fail: Devices that are briefly detected cannot be paired before the scan stops.

  3. Power Management Adjustments Made: Disabling various power management settings (USB autosuspend, runtime power management) did not resolve the issue.

  4. Firmware Loads Successfully: The firmware for the Bluetooth controller (ibt-0041-0041.sfi) loads without error during boot.

Key Diagnostic Output:

  • btmon Diagnostic:
    • Discovery Halts with Busy Status: The btmon diagnostic reveals that after discovery starts, the controller enters a Busy (0x0a) state, which halts the scanning process:
      @ MGMT Event: Command Complete (0x0001) plen 4
Start Discovery (0x0023) plen 1
  Status: Busy (0x0a)
  Address type: 0x07
    BR/EDR
    LE Public
    LE Random
    • The controller briefly enters scan mode and detects a device but then transitions out of discovery:
      hci0 type 7 discovering off
    • Devices Detected and Removed: The detected devices are immediately removed once discovery stops:
      [DEL] Device <MAC>

Information Gathered:

  1. System Configuration:

    • Bluetooth is enabled and powered on:
      Controller 74:3A:F4:33:B2:50 (public)
Powered: yes
Discovering: no

  2. Firmware:

    • The Intel AX210 Bluetooth adapter is using the latest firmware from the linux-firmware package (ibt-0041-0041.sfi).
    • No errors in firmware loading:
      Bluetooth: hci0: Firmware loaded in 1493447 usecs
Bluetooth: hci0: Device booted in 24637 usecs

  3. Power Management:

    • USB Autosuspend: Initially enabled (autosuspend_delay_ms=2000), then set to -1 but the issue persisted.

      cat /sys/module/usbcore/parameters/autosuspend

      Result: 2 (set to -1 but no effect).

    • Runtime Power Management: Initially set to auto, changed to on via:

      echo "on" | sudo tee /sys/bus/usb/devices/1-7/power/control

      Result: The issue persisted.

  4. TLP Settings:

    • TLP is configured to exclude Bluetooth devices from autosuspend (Exclude bluetooth = enabled), but no impact on the issue:
      sudo tlp-stat -u

Key Issues Identified:

  1. Discovery Fails Unexpectedly: Discovery stops unexpectedly (hci0 type 7 discovering off), and detected devices are removed without further log errors.

  2. Power Management Issues: Disabling various power-saving features (autosuspend, runtime power control) had no effect, and the issue continues.

  3. Controller Busy State: The btmon diagnostic reveals a Busy (0x0a) state during the discovery process, which could point to a driver or firmware issue affecting the controller’s ability to complete scanning.

Steps Taken to Address the Issue:

  1. Disabled USB Autosuspend:

    • Disabled USB autosuspend by setting autosuspend_delay_ms to -1. This had no effect on the issue.

  2. Modified Power Management Settings:

    • Configured Bluetooth to have IdleTimeout = -1 and SuspendMode = off in configuration.nix, disabling power management. This did not resolve the issue.

  3. Runtime Power Management:

    • Changed the Bluetooth USB device’s runtime power management setting from auto to on, but the issue persisted.

  4. Full Bluetooth Stack Reset:

    • Restarted the Bluetooth service, killed lingering processes, and reset the Bluetooth controller via rfkill. No improvement in the behavior.

Conclusion:

The Intel AX210 Bluetooth adapter experiences unexpected failures during device discovery on NixOS, despite the latest kernel and firmware being in use. The btmon diagnostic indicates that the controller enters a Busy (0x0a) state, which halts the discovery process prematurely. Disabling autosuspend, power management, and resetting the Bluetooth stack have not resolved the issue. Further investigation into potential driver/firmware issues or kernel-level bugs affecting the AX210 is recommended.

2

Kernel version 6.11.4 has an issue with Bluetooth. Until 6.11.3 it was fine for me on a AX210 BT adapter, but 6.11.4 made my BT mouse disappear. For details see:
https://lore.kernel.org/all/bug-219385-62941-53XRVSyzF4@https.bugzilla.kernel.org%2F/T/
So I stick with an earlier version or wait until it is fixed in a newer than 6.11.4.

1 Like
3

I can confirm that the issue is fixed by downgrading the kernel version to 6.11.3.

Thank you for pointing out the related kernel bug.