On a MacBook Pro running Arch Linux with KDE Plasma, Bluetooth had previously been working normally.<\/p>\n\n\n\n
At some point, Bluetooth suddenly became unavailable. Clicking Enable<\/strong> in KDE’s Bluetooth panel had no effect. The switch could not be turned on, and no Bluetooth devices could be used.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The issue was ultimately recovered without rebooting, reinstalling packages, modifying firmware, or changing the kernel.<\/p>\n\n\n\n The affected system had the following general configuration:<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The KDE Bluetooth interface showed Bluetooth as disabled.<\/p>\n\n\n\n Clicking the Bluetooth enable switch produced no visible result.<\/p>\n\n\n\n The first step was therefore to determine whether the problem was caused by:<\/p>\n\n\n\n The first check was:<\/p>\n\n\n\n The service was running normally:<\/p>\n\n\n\n This immediately showed that Restarting or reinstalling BlueZ was therefore unlikely to address the underlying problem.<\/p>\n\n\n\n Next:<\/p>\n\n\n\n The Bluetooth adapter initially appeared as:<\/p>\n\n\n\n A software block can normally be cleared with:<\/p>\n\n\n\n After doing so:<\/p>\n\n\n\n However, Bluetooth still did not work.<\/p>\n\n\n\n This was an important result.<\/p>\n\n\n\n The rfkill state had been successfully corrected, but the Bluetooth controller was still unavailable. Therefore, rfkill was not the fundamental cause of the failure.<\/p>\n\n\n\n The next commands were:<\/p>\n\n\n\n The result was:<\/p>\n\n\n\n This explains why clicking Enable<\/strong> in KDE did nothing.<\/p>\n\n\n\n KDE was not refusing to enable Bluetooth. There was simply no successfully initialized Bluetooth controller available for KDE or BlueZ to control.<\/p>\n\n\n\n The failure was therefore below the desktop environment.<\/p>\n\n\n\n The relevant kernel messages were obtained with:<\/p>\n\n\n\n The critical messages looked like this:<\/p>\n\n\n\n These messages identify the actual failure.<\/p>\n\n\n\n The Linux Bluetooth stack had created an HCI device, but the Broadcom Bluetooth controller stopped responding during UART initialization.<\/p>\n\n\n\n The most significant error was:<\/p>\n\n\n\n followed by:<\/p>\n\n\n\n Linux error In other words, the driver sent a Broadcom vendor command to the Bluetooth controller and did not receive the expected response.<\/p>\n\n\n\n The software stack can be simplified as:<\/p>\n\n\n\n The upper layers were functioning.<\/p>\n\n\n\n The kernel Bluetooth subsystem loaded normally.<\/p>\n\n\n\n The failure occurred when Therefore, KDE’s inactive Bluetooth switch was only a symptom.<\/p>\n\n\n\n An especially useful diagnostic step was comparing Bluetooth kernel messages from the previous successful boot.<\/p>\n\n\n\n This can be done with:<\/p>\n\n\n\n and comparing them against the current boot:<\/p>\n\n\n\n Interestingly, the previous working boot also reported:<\/p>\n\n\n\n But initialization continued successfully afterward:<\/p>\n\n\n\n The failed boot never reached the Instead, it stopped after:<\/p>\n\n\n\n This difference was crucial.<\/p>\n\n\n\n Because Bluetooth had worked immediately before the failure, a kernel update initially appeared to be a possible cause.<\/p>\n\n\n\n The kernel version from the previous successful boot was compared with the current boot.<\/p>\n\n\n\n Both boots were using the same Linux LTS kernel version.<\/p>\n\n\n\n That largely ruled out a kernel upgrade as the direct trigger of this particular occurrence.<\/p>\n\n\n\n The more likely explanation was therefore a transient hardware\/driver initialization failure:<\/p>\n\n\n\n The Broadcom Bluetooth controller entered an abnormal UART or power state during boot and stopped responding to initialization commands.<\/p>\n<\/blockquote>\n\n\n\n This distinction matters.<\/p>\n\n\n\n Without comparing boots, it would have been easy to incorrectly downgrade the kernel, reinstall BlueZ, or modify firmware.<\/p>\n\n\n\n A full system reboot was not necessary.<\/p>\n\n\n\n The Bluetooth service was stopped first:<\/p>\n\n\n\n Then the Bluetooth UART driver was unloaded:<\/p>\n\n\n\n After a short delay:<\/p>\n\n\n\n the driver was loaded again:<\/p>\n\n\n\n BlueZ was then restarted:<\/p>\n\n\n\n Finally, Bluetooth was unblocked:<\/p>\n\n\n\n The complete recovery sequence is:<\/p>\n\n\n\n No files were modified.<\/p>\n\n\n\n No packages were reinstalled.<\/p>\n\n\n\n No kernel parameters were changed.<\/p>\n\n\n\n No reboot was required.<\/p>\n\n\n\n After reloading the driver:<\/p>\n\n\n\n now returned a valid controller with:<\/p>\n\n\n\n The kernel log also showed successful initialization:<\/p>\n\n\n\n The significant point is that the controller once again progressed beyond the initialization stage where it had previously timed out.<\/p>\n\n\n\n Bluetooth immediately became available to KDE again.<\/p>\n\n\n\n The Broadcom controller on this MacBook communicates with Linux through the Bluetooth UART subsystem.<\/p>\n\n\n\n During the failed boot, the controller entered a state in which it no longer responded correctly to the initialization sequence.<\/p>\n\n\n\n Restarting only:<\/p>\n\n\n\n does not necessarily fix this condition.<\/p>\n\n\n\n That restarts BlueZ in userspace, but the kernel driver and physical controller can remain in the same broken state.<\/p>\n\n\n\n Reloading:<\/p>\n\n\n\n forces the kernel Bluetooth UART driver to detach and initialize the device again.<\/p>\n\n\n\n During the second initialization attempt, the Broadcom controller responded correctly.<\/p>\n\n\n\n This is why restarting BlueZ alone did not solve the problem, while reloading The kernel also reported a warning similar to:<\/p>\n\n\n\n At first glance, this looks suspicious.<\/p>\n\n\n\n However, the same warning was present during a previous boot in which Bluetooth worked normally.<\/p>\n\n\n\n After the runtime recovery, Bluetooth also initialized successfully while the warning remained.<\/p>\n\n\n\n Therefore, in this case:<\/p>\n\n\n\n The missing optional Installing random firmware files would therefore have been an unjustified troubleshooting step.<\/p>\n\n\n\n Other kernel messages may also appear for files such as:<\/p>\n\n\n\n These belong primarily to the 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.<\/p>\n\n\n\n Therefore, a The surrounding log context must be examined.<\/p>\n\n\n\n If the same symptom occurs again and the kernel log contains the same Broadcom UART timeout, the following sequence can be used:<\/p>\n\n\n\n Then verify:<\/p>\n\n\n\n A successful result should contain:<\/p>\n\n\n\n If this command:<\/p>\n\n\n\n returns:<\/p>\n\n\n\n the module should not be force-unloaded with Forcing removal of an in-use kernel module is unnecessary and carries additional risk.<\/p>\n\n\n\n A device-specific unbind\/rebind operation should be used instead.<\/p>\n\n\n\n For similar Bluetooth failures on Linux, the following sequence avoids unnecessary system modifications.<\/p>\n\n\n\n If necessary:<\/p>\n\n\n\n When Bluetooth suddenly cannot be enabled in KDE, the desktop environment is not necessarily responsible.<\/p>\n\n\n\n In this case, the real problem was a temporary initialization failure of the Broadcom Bluetooth controller.<\/p>\n\n\n\n The key symptoms were:<\/p>\n\n\n\n together with:<\/p>\n\n\n\n The controller had failed to respond during the Broadcom UART initialization process.<\/p>\n\n\n\n Reloading the The practical lesson is simple:<\/p>\n\n\n\n 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.<\/p>\n<\/blockquote>\n\n\n\n In this particular failure mode, reloading 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, …<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[122],"tags":[219,292,264],"class_list":["post-6126","post","type-post","status-publish","format-standard","hentry","category-awdn5b6gpb9nez4","tag-arch-linux","tag-bluetooth","tag-troubleshooting"],"_links":{"self":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6126","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/comments?post=6126"}],"version-history":[{"count":1,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6126\/revisions"}],"predecessor-version":[{"id":6127,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/posts\/6126\/revisions\/6127"}],"wp:attachment":[{"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/media?parent=6126"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/categories?post=6126"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.eternalsphere.net\/index.php\/wp-json\/wp\/v2\/tags?post=6126"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n\n\n\nEnvironment<\/h2>\n\n\n\n
\n
\n\n\n\nInitial symptom<\/h2>\n\n\n\n
\n
\n\n\n\nDiagnostic process<\/h1>\n\n\n\n
1. Check the BlueZ service<\/h2>\n\n\n\n
systemctl status bluetooth --no-pager -l\n<\/code><\/pre>\n\n\n\nbluetooth.service - Bluetooth service\nActive: active (running)\nStatus: \"Running\"\n<\/code><\/pre>\n\n\n\nbluetoothd<\/code> itself had not crashed.<\/p>\n\n\n\n
\n\n\n\n2. Check rfkill<\/h2>\n\n\n\n
rfkill list\n<\/code><\/pre>\n\n\n\nBluetooth\n Soft blocked: yes\n Hard blocked: no\n<\/code><\/pre>\n\n\n\nsudo rfkill unblock bluetooth\n<\/code><\/pre>\n\n\n\nSoft blocked: no\nHard blocked: no\n<\/code><\/pre>\n\n\n\n
\n\n\n\n3. Check whether BlueZ can see a controller<\/h2>\n\n\n\n
bluetoothctl list\nbluetoothctl show\n<\/code><\/pre>\n\n\n\nNo default controller available\n<\/code><\/pre>\n\n\n\n
\n\n\n\nKernel log reveals the real problem<\/h1>\n\n\n\n
sudo dmesg -T | grep -iE 'bluetooth|hci0|bcm|hci_uart'\n<\/code><\/pre>\n\n\n\nhci_uart_bcm serial0-0: No reset resource, using default baud rate\n\nBluetooth: hci0: command 0xfc18 tx timeout\nBluetooth: hci0: BCM: failed to write update baudrate (-110)\nBluetooth: hci0: Failed to set baudrate\n\nBluetooth: hci0: command 0xfc18 tx timeout\nBluetooth: hci0: BCM: Reset failed (-110)\n<\/code><\/pre>\n\n\n\ncommand 0xfc18 tx timeout\n<\/code><\/pre>\n\n\n\nBCM: Reset failed (-110)\n<\/code><\/pre>\n\n\n\n-110<\/code> corresponds to a timeout.<\/p>\n\n\n\n
\n\n\n\nWhy this was not a KDE problem<\/h1>\n\n\n\n
KDE Plasma\n \u2193\nBlueZ \/ bluetoothd\n \u2193\nLinux Bluetooth subsystem\n \u2193\nhci_uart\n \u2193\nhci_uart_bcm\n \u2193\nBroadcom Bluetooth controller\n<\/code><\/pre>\n\n\n\nbluetoothd<\/code> was running normally.<\/p>\n\n\n\nrfkill<\/code> could unblock Bluetooth.<\/p>\n\n\n\nhci_uart_bcm<\/code> attempted to communicate with the physical Broadcom controller.<\/p>\n\n\n\n
\n\n\n\nComparing a successful boot with the failed boot<\/h1>\n\n\n\n
journalctl -k -b -1 --no-pager | \\\ngrep -iE 'hci_uart_bcm|Bluetooth: hci0|BCM:'\n<\/code><\/pre>\n\n\n\njournalctl -k -b 0 --no-pager | \\\ngrep -iE 'hci_uart_bcm|Bluetooth: hci0|BCM:'\n<\/code><\/pre>\n\n\n\nBCM: failed to write update baudrate\nFailed to set baudrate\n<\/code><\/pre>\n\n\n\nBCM: chip id 92\nBCM: features 0x2f\nBCM4350C0 UART 37.4 MHz\nBCM build information\n<\/code><\/pre>\n\n\n\nchip id<\/code> stage.<\/p>\n\n\n\ncommand 0xfc18 tx timeout\nBCM: Reset failed (-110)\n<\/code><\/pre>\n\n\n\n
\n\n\n\nKernel regression or temporary controller failure?<\/h1>\n\n\n\n
\n
\n\n\n\nSolution: reload the Bluetooth UART driver<\/h1>\n\n\n\n
sudo systemctl stop bluetooth\n<\/code><\/pre>\n\n\n\nsudo modprobe -r hci_uart\n<\/code><\/pre>\n\n\n\nsleep 2\n<\/code><\/pre>\n\n\n\nsudo modprobe hci_uart\n<\/code><\/pre>\n\n\n\nsudo systemctl start bluetooth\n<\/code><\/pre>\n\n\n\nsudo rfkill unblock bluetooth\n<\/code><\/pre>\n\n\n\nsudo systemctl stop bluetooth\n\nsudo modprobe -r hci_uart\nsleep 2\n\nsudo modprobe hci_uart\nsleep 2\n\nsudo systemctl start bluetooth\nsudo rfkill unblock bluetooth\n<\/code><\/pre>\n\n\n\n
\n\n\n\nVerification<\/h1>\n\n\n\n
bluetoothctl show\n<\/code><\/pre>\n\n\n\nPowered: yes\nPowerState: on\nPairable: yes\n<\/code><\/pre>\n\n\n\nBluetooth: hci0: BCM: chip id 92\nBluetooth: hci0: BCM: features 0x2f\nBluetooth: hci0: BCM4350C0 UART 37.4 MHz\n<\/code><\/pre>\n\n\n\n
\n\n\n\nWhy reloading
hci_uart<\/code> works<\/h1>\n\n\n\nbluetooth.service\n<\/code><\/pre>\n\n\n\nhci_uart\n<\/code><\/pre>\n\n\n\nhci_uart<\/code> did.<\/p>\n\n\n\n
\n\n\n\nAbout the missing BCM firmware warning<\/h1>\n\n\n\n
BCM: firmware Patch file not found\nbrcm\/BCM.hcd\n<\/code><\/pre>\n\n\n\n\n
BCM.hcd<\/code> patch file was not responsible for the sudden Bluetooth failure.<\/p>\n<\/blockquote>\n\n\n\n
\n\n\n\nAbout the Broadcom Wi-Fi firmware warnings<\/h1>\n\n\n\n
brcmfmac4350c2-pcie...\n<\/code><\/pre>\n\n\n\nbrcmfmac<\/code> Wi-Fi driver.<\/p>\n\n\n\nbrcmfmac<\/code> firmware warning should not automatically be interpreted as the cause of an hci_uart_bcm<\/code> Bluetooth failure.<\/p>\n\n\n\n
\n\n\n\nQuick recovery command<\/h1>\n\n\n\n
sudo systemctl stop bluetooth\nsudo modprobe -r hci_uart\nsleep 2\nsudo modprobe hci_uart\nsleep 2\nsudo systemctl start bluetooth\nsudo rfkill unblock bluetooth\n<\/code><\/pre>\n\n\n\nbluetoothctl show\n<\/code><\/pre>\n\n\n\nPowered: yes\n<\/code><\/pre>\n\n\n\n
\n\n\n\nImportant caution<\/h1>\n\n\n\n
sudo modprobe -r hci_uart\n<\/code><\/pre>\n\n\n\nFATAL: Module hci_uart is in use\n<\/code><\/pre>\n\n\n\n-f<\/code>.<\/p>\n\n\n\n
\n\n\n\nRecommended troubleshooting order<\/h1>\n\n\n\n
Check BlueZ<\/h3>\n\n\n\n
systemctl status bluetooth\n<\/code><\/pre>\n\n\n\nCheck rfkill<\/h3>\n\n\n\n
rfkill list\n<\/code><\/pre>\n\n\n\nsudo rfkill unblock bluetooth\n<\/code><\/pre>\n\n\n\nCheck whether a controller exists<\/h3>\n\n\n\n
bluetoothctl list\nbluetoothctl show\n<\/code><\/pre>\n\n\n\nExamine kernel messages<\/h3>\n\n\n\n
sudo dmesg -T | \\\ngrep -iE 'bluetooth|hci0|hci_uart|bcm'\n<\/code><\/pre>\n\n\n\nCompare with the previous boot<\/h3>\n\n\n\n
journalctl -k -b -1 --no-pager | \\\ngrep -iE 'hci_uart_bcm|Bluetooth: hci0|BCM:'\n<\/code><\/pre>\n\n\n\nIf the Broadcom UART controller is stuck<\/h3>\n\n\n\n
sudo systemctl stop bluetooth\nsudo modprobe -r hci_uart\nsleep 2\nsudo modprobe hci_uart\nsleep 2\nsudo systemctl start bluetooth\nsudo rfkill unblock bluetooth\n<\/code><\/pre>\n\n\n\n
\n\n\n\nConclusion<\/h1>\n\n\n\n
No default controller available\n<\/code><\/pre>\n\n\n\ncommand 0xfc18 tx timeout\nBCM: Reset failed (-110)\n<\/code><\/pre>\n\n\n\nhci_uart<\/code> 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.<\/p>\n\n\n\n\n
hci_uart<\/code> can restore Bluetooth without rebooting or modifying the system permanently.<\/p>\n","protected":false},"excerpt":{"rendered":"