Bluetooth (hci_bcm4377) refuses to power on: "Failed (0x03)" Hardware Failure, no timeout, no kernel error

[polarplatypus9090-sudo]

Bluetooth (hci_bcm4377) refuses to power on: "Failed (0x03)" Hardware Failure, no timeout, no kernel error

Summary

On a MacBookPro15,4 (13" 2019, 2x TB), the Bluetooth controller (hci_bcm4377, BCM4377B3 "formosa") probes cleanly on every boot with no -110/timeout errors, but any attempt to power it on — via bluetoothctl power on, a desktop toolbar applet, or rfkill unblock — is immediately refused by the firmware with an explicit Failed (0x03) (Bluetooth HCI "Hardware Failure") status. No kernel-level error accompanies this response; bluetoothd just reports the refusal.

This is fully reproducible across multiple clean reboots, and reproduces identically whether or not any third-party Bluetooth software is installed (see "Ruling out third-party software" below).

Hardware

• Model: MacBookPro15,4 (Mac-53FDB3D8DB8CA971)
• BIOS/EFI: 2094.80.5.0.0 (iBridge 23.16.13120.0.0,0)
• Bluetooth/WiFi combo chip: Broadcom BCM4377 (PCI 14e4:5fa0, function 0000:01:00.1), firmware variant brcm/brcmbt4377b3-apple,formosa
• WiFi (brcmfmac, same combo chip, function 0000:01:00.0) works correctly — connects normally, no errors. This isolates the problem to the Bluetooth function specifically, not the whole chip/firmware load path.

Software

• Distro: Omarchy 4.0.1 (Arch-based)
• Kernel: 7.1.8-arch1-Watanare-T2-3-t2 (package linux-t2 7.1.8.arch1-3)
• bluez 5.87-2
• apple-bcm-firmware 14.0-1

Steps to reproduce

1. Cold boot (not resume from suspend/hibernate).
2. bluetoothctl show — controller is present with a valid public address, but Powered: no.
3. bluetoothctl power on

Expected

Controller powers on (Powered: yes).

Actual

[CHG] Controller A4:83:E7:86:03:AF PowerState: off-enabling
Failed to set power on: org.bluez.Error.Failed
[CHG] Controller A4:83:E7:86:03:AF PowerState: on

bluetoothd[...]: Failed to set mode: Failed (0x03)

bluetoothctl show afterward still reports Powered: no.

Checked in parallel with journalctl -k --since <attempt window>: no kernel-level message is logged for this specific failure — no timeout, no opcode failure, nothing. The refusal appears to originate from the controller's own firmware response to the MGMT power-on request, not from a driver/comms-layer error.

Boot-time kernel log (clean, no timeouts)

Bluetooth: Core ver 2.22
NET: Registered PF_BLUETOOTH protocol family
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
hci_bcm4377 0000:01:00.1: can't disable ASPM; OS doesn't have ASPM control
hci_bcm4377 0000:01:00.1: resetting
hci_bcm4377 0000:01:00.1: reset done
hci_bcm4377 0000:01:00.1: enabling device (0000 -> 0002)
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac4377b3-pcie for chip BCM4377/4
brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4377/4 wl0: Jul  8 2023 00:34:19 version 16.20.371.0.3.6.125 FWID 01-52f5532e
hci_bcm4377 0000:01:00.1: failed to destroy transfer ring 6
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: BNEP socket layer initialized
Bluetooth: MGMT ver 1.23
hci_bcm4377 0000:01:00.1: failed to destroy transfer ring 5
hci_bcm4377 0000:01:00.1: failed to destroy transfer ring 4
hci_bcm4377 0000:01:00.1: failed to destroy transfer ring 3
hci_bcm4377 0000:01:00.1: failed to destroy transfer ring 2
hci_bcm4377 0000:01:00.1: failed to destroy transfer ring 1
hci_bcm4377 0000:01:00.1: failed to destroy completion ring 4
hci_bcm4377 0000:01:00.1: failed to destroy completion ring 3
hci_bcm4377 0000:01:00.1: failed to destroy completion ring 2
hci_bcm4377 0000:01:00.1: failed to destroy completion ring 1
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11

Note the repeated failed to destroy transfer/completion ring N lines during every single boot's bring-up (not just after a reset/reload) — happens before the controller has ever been asked to power on. Not sure if this is benign or related to the later power-on refusal; flagging it since it's consistent and unusual.

/sys/class/bluetooth/hci0 exists and /sys/bus/pci/devices/0000:01:00.1/enable reads 1, so the PCI function is bound and the driver considers itself attached — this is not a probe failure or an unbound device. rfkill list shows Bluetooth soft/hard blocked: no.

Ruling out third-party software

This machine had blueferry (an iPhone↔Linux Bluetooth bridge, packages blueferry-backend/-gtk/-qt/-quickshell) installed, which ships a bluetooth.service.d drop-in that adds -E to bluetoothd's ExecStart. The exact same Failed (0x03) power-on refusal was observed:

• Before installing blueferry
• While blueferry's drop-in was active
• After fully uninstalling blueferry (pacman -Rns) and removing the drop-in, confirmed via systemctl status bluetooth.service showing no active drop-ins and bluetoothd running with its stock ExecStart (no -E)

So this is not caused by blueferry or any Bluetooth-adjacent userspace package — it reproduces on a stock bluetoothd/BlueZ setup.

Possibly related but distinct

I found two other recent open issues against the same kernel build (7.1.8-arch1-Watanare-T2-3-t2) but a different board (MacBookPro15,2, Mac-827FB448E656EC26): #22 / t2linux/wiki#746, describing t2bce_vhci desync/timeout and GPF crashes after hibernate resume, plus "malformed Bluetooth advertising packets." Those reproduce only after hibernation; this issue reproduces on a cold boot, has no t2bce_vhci involvement, and the Bluetooth controller returns a clean, immediate HCI error status rather than timing out. Flagging the overlap in case it's a related regression, but treating it as a separate report since the trigger and symptom differ.

Ask

Has anyone seen the BCM4377B3 "formosa" variant specifically return Failed (0x03) on power-on with no accompanying kernel/timeout error? Happy to gather a btmon HCI trace of the power-on attempt if that would help narrow this down — didn't have root/TTY access to capture one for this report.

[polarplatypus9090-sudo]

Update: tried pcie_aspm=force, ruled out as a fix

Given the driver's own can't disable ASPM; OS doesn't have ASPM control message on boot, and the upstream commit converting ASPM-disable to a required quirk for this chip, I tried forcing OS ASPM control via the kernel parameter pcie_aspm=force.

Effect on boot log: the can't disable ASPM line disappeared, and a plain bluetoothctl power on succeeded (Powered: yes) without the Failed (0x03) refusal from the original report.

But real use is still broken. The moment any actual command traffic is needed — e.g. starting a scan to pair a device — the same class of failure returns:

Bluetooth: hci0: Opcode 0x2005 failed: -110      (LE Set Random Address)
Bluetooth: hci0: Opcode 0x200b failed: -110      (LE Set Scan Enable)
Bluetooth: hci0: command 0x0c56 tx timeout

repeating every ~2s while scan on was active. bluetoothd eventually gave up on the D-Bus call itself:

Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

and the controller reverted to Powered: no on its own afterward.

Also worth noting: on two earlier boots (before trying pcie_aspm=force), the boot-time log had zero -110/timeout entries at all, then this most recent boot (with the parameter applied) had them again. So the presence/absence of these command timeouts looks intermittent across boots independent of the ASPM setting — pcie_aspm=force changed the boot-time symptom signature but doesn't appear to address the actual root cause, and I can't confirm it helps at all now that I've seen it fail under real use.

Net: still unable to actually pair/use Bluetooth on this machine. Leaving pcie_aspm=force in place since it's harmless, but flagging that it should not be assumed to be a working workaround for this issue.