Symptom
On a MacBook Pro running Arch Linux with KDE Plasma, Bluetooth had previously been working normally.
At some point, Bluetooth suddenly became unavailable. Clicking Enable in KDE’s Bluetooth panel had no effect. The switch could not be turned on, and no Bluetooth devices could be used.
At first glance, this looked like a KDE or BlueZ problem. Command-line diagnostics showed that the actual cause was lower in the stack: the Broadcom Bluetooth controller had failed to initialize correctly during boot.
The issue was ultimately recovered without rebooting, reinstalling packages, modifying firmware, or changing the kernel.
Environment
The affected system had the following general configuration:
- MacBook Pro
- Arch Linux
- KDE Plasma
- BlueZ
- Linux LTS kernel
- Broadcom BCM4350-series wireless hardware
The MacBook uses a Broadcom wireless combination device. Wi-Fi and Bluetooth are handled through different Linux driver paths, even though they belong to the same physical wireless hardware.
Initial symptom
The KDE Bluetooth interface showed Bluetooth as disabled.
Clicking the Bluetooth enable switch produced no visible result.
The first step was therefore to determine whether the problem was caused by:
- KDE Plasma
- BlueZ
- rfkill
- the Bluetooth kernel subsystem
- the Broadcom driver
- firmware
- or the Bluetooth controller itself
Diagnostic process
1. Check the BlueZ service
The first check was:
systemctl status bluetooth --no-pager -l
The service was running normally:
bluetooth.service - Bluetooth service
Active: active (running)
Status: "Running"
This immediately showed that bluetoothd itself had not crashed.
Restarting or reinstalling BlueZ was therefore unlikely to address the underlying problem.
2. Check rfkill
Next:
rfkill list
The Bluetooth adapter initially appeared as:
Bluetooth
Soft blocked: yes
Hard blocked: no
A software block can normally be cleared with:
sudo rfkill unblock bluetooth
After doing so:
Soft blocked: no
Hard blocked: no
However, Bluetooth still did not work.
This was an important result.
The rfkill state had been successfully corrected, but the Bluetooth controller was still unavailable. Therefore, rfkill was not the fundamental cause of the failure.
3. Check whether BlueZ can see a controller
The next commands were:
bluetoothctl list
bluetoothctl show
The result was:
No default controller available
This explains why clicking Enable in KDE did nothing.
KDE was not refusing to enable Bluetooth. There was simply no successfully initialized Bluetooth controller available for KDE or BlueZ to control.
The failure was therefore below the desktop environment.
Kernel log reveals the real problem
The relevant kernel messages were obtained with:
sudo dmesg -T | grep -iE 'bluetooth|hci0|bcm|hci_uart'
The critical messages looked like this:
hci_uart_bcm serial0-0: No reset resource, using default baud rate
Bluetooth: hci0: command 0xfc18 tx timeout
Bluetooth: hci0: BCM: failed to write update baudrate (-110)
Bluetooth: hci0: Failed to set baudrate
Bluetooth: hci0: command 0xfc18 tx timeout
Bluetooth: hci0: BCM: Reset failed (-110)
These messages identify the actual failure.
The Linux Bluetooth stack had created an HCI device, but the Broadcom Bluetooth controller stopped responding during UART initialization.
The most significant error was:
command 0xfc18 tx timeout
followed by:
BCM: Reset failed (-110)
Linux error -110 corresponds to a timeout.
In other words, the driver sent a Broadcom vendor command to the Bluetooth controller and did not receive the expected response.
Why this was not a KDE problem
The software stack can be simplified as:
KDE Plasma
↓
BlueZ / bluetoothd
↓
Linux Bluetooth subsystem
↓
hci_uart
↓
hci_uart_bcm
↓
Broadcom Bluetooth controller
The upper layers were functioning.
bluetoothd was running normally.
rfkill could unblock Bluetooth.
The kernel Bluetooth subsystem loaded normally.
The failure occurred when hci_uart_bcm attempted to communicate with the physical Broadcom controller.
Therefore, KDE’s inactive Bluetooth switch was only a symptom.
Comparing a successful boot with the failed boot
An especially useful diagnostic step was comparing Bluetooth kernel messages from the previous successful boot.
This can be done with:
journalctl -k -b -1 --no-pager | \
grep -iE 'hci_uart_bcm|Bluetooth: hci0|BCM:'
and comparing them against the current boot:
journalctl -k -b 0 --no-pager | \
grep -iE 'hci_uart_bcm|Bluetooth: hci0|BCM:'
Interestingly, the previous working boot also reported:
BCM: failed to write update baudrate
Failed to set baudrate
But initialization continued successfully afterward:
BCM: chip id 92
BCM: features 0x2f
BCM4350C0 UART 37.4 MHz
BCM build information
The failed boot never reached the chip id stage.
Instead, it stopped after:
command 0xfc18 tx timeout
BCM: Reset failed (-110)
This difference was crucial.
Kernel regression or temporary controller failure?
Because Bluetooth had worked immediately before the failure, a kernel update initially appeared to be a possible cause.
The kernel version from the previous successful boot was compared with the current boot.
Both boots were using the same Linux LTS kernel version.
That largely ruled out a kernel upgrade as the direct trigger of this particular occurrence.
The more likely explanation was therefore a transient hardware/driver initialization failure:
The Broadcom Bluetooth controller entered an abnormal UART or power state during boot and stopped responding to initialization commands.
This distinction matters.
Without comparing boots, it would have been easy to incorrectly downgrade the kernel, reinstall BlueZ, or modify firmware.
Solution: reload the Bluetooth UART driver
A full system reboot was not necessary.
The Bluetooth service was stopped first:
sudo systemctl stop bluetooth
Then the Bluetooth UART driver was unloaded:
sudo modprobe -r hci_uart
After a short delay:
sleep 2
the driver was loaded again:
sudo modprobe hci_uart
BlueZ was then restarted:
sudo systemctl start bluetooth
Finally, Bluetooth was unblocked:
sudo rfkill unblock bluetooth
The complete recovery sequence is:
sudo systemctl stop bluetooth
sudo modprobe -r hci_uart
sleep 2
sudo modprobe hci_uart
sleep 2
sudo systemctl start bluetooth
sudo rfkill unblock bluetooth
No files were modified.
No packages were reinstalled.
No kernel parameters were changed.
No reboot was required.
Verification
After reloading the driver:
bluetoothctl show
now returned a valid controller with:
Powered: yes
PowerState: on
Pairable: yes
The kernel log also showed successful initialization:
Bluetooth: hci0: BCM: chip id 92
Bluetooth: hci0: BCM: features 0x2f
Bluetooth: hci0: BCM4350C0 UART 37.4 MHz
The significant point is that the controller once again progressed beyond the initialization stage where it had previously timed out.
Bluetooth immediately became available to KDE again.
Why reloading hci_uart works
The Broadcom controller on this MacBook communicates with Linux through the Bluetooth UART subsystem.
During the failed boot, the controller entered a state in which it no longer responded correctly to the initialization sequence.
Restarting only:
bluetooth.service
does not necessarily fix this condition.
That restarts BlueZ in userspace, but the kernel driver and physical controller can remain in the same broken state.
Reloading:
hci_uart
forces the kernel Bluetooth UART driver to detach and initialize the device again.
During the second initialization attempt, the Broadcom controller responded correctly.
This is why restarting BlueZ alone did not solve the problem, while reloading hci_uart did.
About the missing BCM firmware warning
The kernel also reported a warning similar to:
BCM: firmware Patch file not found
brcm/BCM.hcd
At first glance, this looks suspicious.
However, the same warning was present during a previous boot in which Bluetooth worked normally.
After the runtime recovery, Bluetooth also initialized successfully while the warning remained.
Therefore, in this case:
The missing optional
BCM.hcdpatch file was not responsible for the sudden Bluetooth failure.
Installing random firmware files would therefore have been an unjustified troubleshooting step.
About the Broadcom Wi-Fi firmware warnings
Other kernel messages may also appear for files such as:
brcmfmac4350c2-pcie...
These belong primarily to the brcmfmac Wi-Fi driver.
A Broadcom Wi-Fi/Bluetooth combination chip contains multiple functional interfaces, and Linux does not necessarily initialize Wi-Fi and Bluetooth through the same driver.
Therefore, a brcmfmac firmware warning should not automatically be interpreted as the cause of an hci_uart_bcm Bluetooth failure.
The surrounding log context must be examined.
Quick recovery command
If the same symptom occurs again and the kernel log contains the same Broadcom UART timeout, the following sequence can be used:
sudo systemctl stop bluetooth
sudo modprobe -r hci_uart
sleep 2
sudo modprobe hci_uart
sleep 2
sudo systemctl start bluetooth
sudo rfkill unblock bluetooth
Then verify:
bluetoothctl show
A successful result should contain:
Powered: yes
Important caution
If this command:
sudo modprobe -r hci_uart
returns:
FATAL: Module hci_uart is in use
the module should not be force-unloaded with -f.
Forcing removal of an in-use kernel module is unnecessary and carries additional risk.
A device-specific unbind/rebind operation should be used instead.
Recommended troubleshooting order
For similar Bluetooth failures on Linux, the following sequence avoids unnecessary system modifications.
Check BlueZ
systemctl status bluetooth
Check rfkill
rfkill list
If necessary:
sudo rfkill unblock bluetooth
Check whether a controller exists
bluetoothctl list
bluetoothctl show
Examine kernel messages
sudo dmesg -T | \
grep -iE 'bluetooth|hci0|hci_uart|bcm'
Compare with the previous boot
journalctl -k -b -1 --no-pager | \
grep -iE 'hci_uart_bcm|Bluetooth: hci0|BCM:'
If the Broadcom UART controller is stuck
sudo systemctl stop bluetooth
sudo modprobe -r hci_uart
sleep 2
sudo modprobe hci_uart
sleep 2
sudo systemctl start bluetooth
sudo rfkill unblock bluetooth
Conclusion
When Bluetooth suddenly cannot be enabled in KDE, the desktop environment is not necessarily responsible.
In this case, the real problem was a temporary initialization failure of the Broadcom Bluetooth controller.
The key symptoms were:
No default controller available
together with:
command 0xfc18 tx timeout
BCM: Reset failed (-110)
The controller had failed to respond during the Broadcom UART initialization process.
Reloading the hci_uart kernel driver forced the Bluetooth hardware through a fresh initialization cycle, after which the BCM4350 controller was detected correctly and Bluetooth returned to normal operation.
The practical lesson is simple:
When BlueZ is running but no Bluetooth controller exists, troubleshooting should move below KDE and BlueZ into the kernel HCI driver and hardware initialization layer.
In this particular failure mode, reloading hci_uart can restore Bluetooth without rebooting or modifying the system permanently.