Bluetooth connections not possible after sleep

pjjjv · May 31, 2026, 1:31pm

Either as of upgrade to Fedora 44 from 43, or after resynchronizing the firmware from within MacOS using the asahi script new option, sleeping the laptop creates a problem for bluetooth connection.

The error is “Failed to connect: org.bluez.Error.Failed le-connection-abort-by-local” if I manually try to reconnect to a bluetooth device after sleep.

pjjjv · May 31, 2026, 2:15pm

The Broadcom chip’s firmware is failing to transition to the low-power D3 state during sleep, causing subsequent re-initialization failures.

Technical Root Cause

D3 Timeout: The log shows brcmfmac 0000:01:00.0: brcmf_pcie_pm_enter_D3: Timeout on response for entering D3 substate.
Failed Suspend: Because the chip failed to enter the low-power (D3) state properly, it stayed in a “half-broken” state.
Communication Breakdown: When I woke the laptop, the kernel tried to talk to the chip (brcmf_pcie_send_mb_data), but it failed with error -12 (Cannot allocate memory/Out of
resources). At this point, the hardware was unresponsive to the driver.

pjjjv · May 31, 2026, 7:28pm

github.com/AsahiLinux/linux

wifi/bluetooth: Broadcom BCM4387 D3 suspend timeout and coordination race

opened 07:11PM - 31 May 26 UTC

pjjjv

### Description The Broadcom BCM4387 PCIe device consistently fails to enter the… D3 power state during system suspend on the MacBook Pro M1. This results in the hardware entering an unrecoverable state or timing out upon resume. ### System Information - **Hardware:** MacBook Pro M1 (Apple Silicon) - **OS:** Fedora Asahi Remix 44 - **Kernel Version:** 6.19.14-400.asahi.fc44.aarch64+16k - **PCIe Devices:** - WiFi: `01:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4387 [14e4:4433] (rev 07)` - Bluetooth: `01:00.1 Network controller: Broadcom Inc. and subsidiaries BRCM4387 Bluetooth Controller [14e4:5f71] (rev 07)` ### Root Causes The failure stems from three primary architectural issues in how the Asahi-specific drivers interact with the BCM4387 firmware: 1. **MsgBuf Ring Congestion:** Unlike the simpler MMIO-based handshake in older kernel versions, the Asahi driver sends the `D3_INFORM` sleep request via the complex Message Buffer (MsgBuf) control ring. During suspend, this ring can become congested with pending transactions. If the driver encounters an `ENOMEM (-12)` error, the sleep command is never successfully enqueued, leaving the firmware unaware of the impending power-down. 2. **Cross-Function Race Condition:** The WiFi (01:00.0) and Bluetooth (01:00.1) components are sibling functions on the same physical chip. Both drivers independently attempt to manage the shared `BAR0_SLEEP_CONTROL` register. If the Bluetooth driver writes `QUIESCE` to this register while the WiFi driver is still awaiting its `D3_ACK` response from the firmware, the device's execution environment hangs, resulting in the observed timeouts. 3. **Fragile Handshake Timing:** The default 2-second timeout (`BRCMF_PCIE_MBDATA_TIMEOUT`) is often insufficient for the firmware to process connection teardowns for multiple HID devices while simultaneously acknowledging power-state transitions. ### Reproduction Steps 1. Boot the standard Asahi Linux kernel. 2. Put the machine to sleep manually: ```bash sudo systemctl suspend ``` 3. Wake the machine. 4. Observe that the WiFi/Bluetooth connectivity fails or hangs upon resume, accompanied by timeout messages in `dmesg`. Bluetooth HID devices that were connected before the sleep can no longer be connected to. ### Relevant Error Logs Typical log signatures during suspend failure: ``` brcmfmac: brcmf_pcie_pm_enter_D3: Timeout on response for entering D3 substate brcmfmac: Failed to send H2D mailbox data (-12) hci_bcm4377 0000:01:00.1: Timeout waiting for RTI state transition ``` ### Solution Strategy To resolve this, the drivers must move from independent power management to **Coordinated Sibling Quiescence**. The strategy centers on: - Synchronizing the sibling functions so that the hardware-level quiesce only occurs after both drivers have completed their respective firmware-level handshakes. - Hardening the Message Buffer communication path during the critical suspend window by increasing grace periods and ensuring that previously ignored error codes (like `-12` and `-5`) trigger appropriate fallback or retry logic. ### Fixes 1. **WiFi Driver:** Increased `BRCMF_PCIE_MBDATA_TIMEOUT` to 5 seconds and added return code validation to `brcmf_pcie_pm_enter_D3`. 2. **Bluetooth Driver:** Added retry loops on `bootstage` and `rti_status` checks in `bcm4377_boot` to allow slower wakeups. 3. **Coordinated Quiesce:** Modified `bcm4377_suspend` to locate the sibling WiFi PCI function (function 0) and wait until it transitions to `PCI_D3hot` or `PCI_D3cold` before writing `BCM4377_BAR0_SLEEP_CONTROL_QUIESCE`. ### Testing Verified on the MacBook Pro M1 with the custom kernel `6.19.14-suspendfix+`. Multiple consecutive manual suspends and resumes successfully retained WiFi and Bluetooth connectivity without timeouts or driver hangs.

Topic		Replies	Views
Bluetooth stops working after sleep Ask Fedora f36 , bluetooth , silverblue	7	3607	September 15, 2024
Bluetooth stops working after returning from sleep Ask Fedora kde , wayland , bluetooth , f43	0	70	April 16, 2026
F41 + Acer Aspire 5 - Bluetooth stops working after resuming from suspend Ask Fedora cinnamon , bluetooth , acer , f41	1	94	March 19, 2025
Loosing BT Mouse and keyboard after sleep Ask Fedora bluetooth , f43	1	52	February 5, 2026
Fedora 36 KDE - Suspend issues with Bluetooth Enabled Ask Fedora f36	4	1709	July 23, 2023

Bluetooth connections not possible after sleep

Related topics