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

Activity

1. polarplatypus9090-sudo commented on Aug 28, 2026

   

   polarplatypus9090-sudo

   on Aug 28, 2026

   Author

   More actions

   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.
2. ReneXiong commented on Sep 10, 2026

   

   ReneXiong

   on Sep 10, 2026

   Last edited by ReneXiong

   More actions

   Update: recovered with PCI function reset followed by explicit driver bind

   I reproduced this again on a MacBookPro15,4 (13-inch, 2019, Intel Core i5), now with the following software/firmware. MacBookPro15,4 is Apple's model identifier, not the screen size:

   • Omarchy 4.0.3-1
   • linux-t2 7.2.3.arch1-2 (7.2.3-arch1-Watanare-T2-2-t2)
   • bluez 5.87-2, bluez-utils 5.87-2
   • apple-bcm-firmware 14.0-1
   • New t2bce stack (t2bce_core, t2bce_vhci, and t2bce_audio loaded)
   • BIOS 2103.160.2.0.0, iBridge 23.16.16068.0.0,0

   This boot showed a stronger failure mode than the original report. Immediately after the driver's initial reset done, HCI commands repeatedly timed out:

   hci_bcm4377 0000:01:00.1: resetting
   hci_bcm4377 0000:01:00.1: reset done
   Bluetooth: hci0: command 0x0c56 tx timeout
   Bluetooth: hci0: Opcode 0x0c56 failed: -110
   Bluetooth: hci0: Opcode 0x0c24 failed: -110
   

   A normal module unload/reload did not recover it. Unload produced timeouts while destroying transfer/completion rings, and the subsequent probe failed:

   hci_bcm4377 0000:01:00.1: failed to destroy transfer ring 6
   ...
   hci_bcm4377 0000:01:00.1: failed to destroy completion ring 1
   hci_bcm4377 0000:01:00.1: probe with driver hci_bcm4377 failed with error -110
   

   At that point the module was loaded but the PCI function was unbound. The following sequence recovered the controller:

   echo 1 > /sys/bus/pci/devices/0000:01:00.1/reset
   echo 0000:01:00.1 > /sys/bus/pci/drivers/hci_bcm4377/bind

   After the explicit bind:

   • lspci -nnk -s 01:00.1 reported Kernel driver in use: hci_bcm4377.
   • BlueZ exposed the controller again.
   • A complete power-off/power-on round trip succeeded.
   • No new HCI opcode failures or transmit timeouts appeared in the kernel log.

   I installed a local boot-time oneshot workaround that first tries the BlueZ Powered D-Bus property and only performs unbind -> PCI function reset -> bind if that operation fails. The manual recovery path above has been verified once so far; I have not yet completed a multi-cold-boot test matrix.

   This may help narrow the issue: the probe path already attempts a function-level reset internally, but in this failure state an explicit reset while unbound, followed by a fresh bind, succeeded where a normal module reload did not.