I have encountered an issue where the Bluetooth devices randomly stop working. When this happens, if I open the bluetooth’s setting in Gnome it shows that it is powered on, however nothing responds. When I try to reset it with the switch at the top, it stays gray and stops showing the devices.
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 003: ID 0bda:c123 Realtek Semiconductor Corp. Bluetooth Radio
Bus 003 Device 002: ID 04f3:0c4b Elan Microelectronics Corp. ELAN:Fingerprint
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 04f2:b725 Chicony Electronics Co., Ltd Integrated Camera
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
bluetoothctl
[Bluetooth Mouse M336/M337/M535]# power off
Changing power off succeeded
[CHG] Device XX:XX:XX:XX:XX:XX Connected: no
[CHG] Device XX:XX:XX:XX:XX:XX Connected: no
[CHG] Controller XX:XX:XX:XX:XX:XX Powered: no
[CHG] Controller XX:XX:XX:XX:XX:XX Discovering: no
[CHG] Controller XX:XX:XX:XX:XX:XX Class: 0x00000000
[bluetooth]# power on
Failed to set power on: org.bluez.Error.Failed
[bluetooth]# power on
Failed to set power on: org.bluez.Error.Busy
Also, running the following command does not work: sudo rfkill block bluetooth;sudo rfkill unblock bluetooth;sudo systemctl restart bluetooth.service
My issue occurs some minutes after reboot. Actually, if suspend for a few hours, bluetooth starts working again. Which is the opposite of the reported issue you mentioned.
However, I have downgraded from bluez-5.64-1.fc35.x86_64 to bluez-5.61-1.fc35.x86_64, and I will test if it solves it.
I’m not sure (I don’t have enough technical expertise), but I’m afraid that in kernels > 5.4 some problem has been introduced in dynamic suspend. As I wrote in another conversation, in my case I solved the problem by preventing any autosuspend by setting the value of usbcore.autosuspend to -1.
You should edit the
/etc/default/grub
file by adding:
usbcore.autosuspend=-1
to the GRUB_CMDLINE_LINUX entry.
Then, in order to create a new grub2 configuration file:
# grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
After rebooting the system the “autosuspend” parameter should have value -1.
The thing is that my issue happens even if I haven’t suspended my machine while I’m working. Sometimes it even occurs a minute after I have power on the machine. So, I don’t think it is related to suspension mechanism.
As I have mentioned earlier, suspending the machine for a few hours actually solves the issue, rather than causing it.
I have been testing @glb proposal and the issue hasn’t repeated, while before it happened like 10 times a day. I will keep testing it for a week before marking it as the solution.
I wouldn’t really consider downgrading a package as a “solution”. You may well find that you need to upgrade it at some point in order to get some other needed feature or security patch. Proving that the functionality changes when the package is downgraded just helps to narrow down where the problem lies. The next step would be to search the issues in the git repo to see if there is an existing/known match for your problem and report a new issue if you don’t find one. The problem would be solved when a new package is released that no longer exhibits the broken behavior.
Actually, “dynamic suspend” refers to suspending individual devices while the system remains running. Also in my case the bluetooth devices would disconnect frequently, without having suspended the entire system, with the identical behavior you described in the first post. That’s why I assumed your problem was similar to mine.