After upgrading to kernel 4.16 (4.16.0-2-ARCH), my intel 8265 bluetooth device has stopped functioning.
`bluetoothctl list` is empty and `bluetoothctl power on` reports "No default controller available".
With the previous kernel I was using, 4.15.15, the device worked correctly.
I am willing to bisect and/or apply patches but it will be slow on my end. I do see some significant restructuring of the boot process and firmware loading in drivers/bluetooth/*intel* between 4.15 and 4.16, but I haven't been able to test if reverting any of those commits makes a difference.
Does it never work for you?
I think I'm experiencing a similar issue with a CSL bluetooth device that worked just fine before 4.16, but now it only works for some time and then disappears completely (also from lsusb).
However, it usually works when I just started the system.
Sometimes replugging the device does bring it back.
It might be related to the BTLE changes made between 4.15 and 4.16.
That sounds like a different issue from mine. Mine stays visible in lsusb, but it never seems to register as a bluetooth controller.
I'm not a bt guy, but I'd try to see if there is a newer firmware in linux-firmware.git that the new driver may be looking for.
This new firmware would be under intel/
The newer firmware in linux-firmware.git makes no difference -- the older and newer firmware both work on 4.15 and both fail on 4.16.
I started a git bisect on the kernel but it will likely be another day or two before I'll be able to get around to finishing it.
ok so this is what I could do.
(not a BT guy).
I believe I have found the culprit: commit eff2d68ca7388ee1c08811c6bbf4d8587cba01da enables btusb autosuspend by default given a certain Kconfig option, and I confirmed that Arch Linux did opt in to it.
Appending `btusb.enable_autosuspend=n` to my kernel command line has effectively solved my issue as far as I am concerned.
I had discovered that autosuspend "broke" my bluetooth device a long time ago, but it hasn't crossed my mind for a while. The actual bug here is that autosuspend causes the bluetooth device to stop working.
Interesting, because that's exactly the option that I found to cause my problem as well, even though the outcome seems to be different. ;)