+++ This bug was initially created as a clone of Bug #1711468 +++ 1. Please describe the problem: Bluetooth is not working at all in current (5.0.16-100.fc28.x86_64) kernel on a bog-standard lenovo yoga 900. failing from the first reboot after updating . It was working perfectly in 5.0.9-100.fc28.x86_64. Bluetooth is still working perfectly when booted to windows 10 (i.e. it doesn't seem to be a hardware issue). I will attach lsusb -v output after submitting this report. I'm sorry, I won't be able to give much further feedback. I have arthritis that makes using the trackpad very painful. I will have to revert to kernel 5.0.9-100.fc28.x86_6 as soon as I finish this report, so that I can resume using the bluetooth mouse. 2. What is the Version-Release number of the kernel: 5.0.16-100.fc28.x86_64 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Yes. Just appeared in 5.0.16-100.fc28.x86_64 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes. Just reboot. Never works. 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Sorry, this is my primary work machine, I can't risk experimenting with it. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. See below. --- Additional comment from bob mckay on 2019-05-17 21:50 UTC --- --- Additional comment from bob mckay on 2019-05-17 22:46:24 UTC --- Apologies, please read all references to the preceding (working) kernel in the initial report as being to 5.0.13-100.fc28, rather than to 5.0.9-100.fc28 (I'd edit the report if I could find a way, but I'm guessing it's read-only to preserve the history trace). It seems it's not easy to revert a kernel update, so I'll just be booting to the previous kernel, meaning that I can relatively easily boot to 5.0.16-100.fc28.x86_64 if further detail is needed. Also, it's quite possible that this bug should be allocated to the kernel-modules package rather than the kernel, I'm sorry, I just don't know enough about the kernel/modules structure to figure out where the problem lies. --- Additional comment from Didier G on 2019-05-18 13:11:46 UTC --- I confirm this problem. Configuration: *-usb description: USB controller product: Sunrise Point-LP USB 3.0 xHCI Controller vendor: Intel Corporation physical id: 14 bus info: pci@0000:00:14.0 version: 21 width: 64 bits clock: 33MHz capabilities: pm msi xhci bus_master cap_list configuration: driver=xhci_hcd latency=0 resources: irq:125 memory:dfb10000-dfb1ffff *-usbhost:0 product: xHCI Host Controller vendor: Linux 5.0.11-300.fc30.x86_64 xhci-hcd physical id: 0 bus info: usb@1 logical name: usb1 version: 5.00 capabilities: usb-2.00 configuration: driver=hub slots=12 speed=480Mbit/s *-usb:1 description: Bluetooth wireless interface vendor: Intel Corp. physical id: 8 bus info: usb@1:8 version: 0.01 capabilities: bluetooth usb-2.01 configuration: driver=btusb maxpower=100mA speed=12Mbit/s BT mouse Logitech M555b Works fine with kernel 5.0.11 Does not connect with both kernel 5.0.16 and 5.1.3 --- Additional comment from Didier G on 2019-05-18 13:59:03 UTC --- I did bisect. For me and in my BT configuration, last working kernel is 5.0.14. According changelog, not working kernel 5.0.15 includes these changes: Chen-Yu Tsai (1): Bluetooth: hci_bcm: Fix empty regulator supplies for Intel Macs Luiz Augusto von Dentz (1): Bluetooth: Fix not initializing L2CAP tx_credits Marcel Holtmann (1): Bluetooth: Align minimum encryption key size for LE and BR/EDR connections Young Xiao (1): Bluetooth: hidp: fix buffer overflow --- Additional comment from Didier G on 2019-05-20 13:42:30 UTC --- This is the messages I get when I enabled BT then try to connect to my BT mouse using kernel 4.0.15: mai 20 15:30:06 laptop.home systemd[1]: Starting Load/Save RF Kill Switch Status... mai 20 15:30:06 laptop.home systemd[1]: Started Load/Save RF Kill Switch Status. mai 20 15:30:06 laptop.home audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' mai 20 15:30:11 laptop.home systemd[1]: systemd-rfkill.service: Succeeded. mai 20 15:30:11 laptop.home audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-rfkill comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' mai 20 15:30:46 laptop.home bluetoothd[791]: Can't get HIDP connection info mai 20 15:30:46 laptop.home bluetoothd[791]: connect error: Device or resource busy (16) mai 20 15:30:49 laptop.home bluetoothd[791]: Can't get HIDP connection info mai 20 15:30:55 laptop.home bluetoothd[791]: connect error: Host is down (112) mai 20 15:31:02 laptop.home bluetoothd[791]: Can't get HIDP connection info mai 20 15:31:02 laptop.home bluetoothd[791]: connect error: Device or resource busy (16) mai 20 15:31:14 laptop.home bluetoothd[791]: Can't get HIDP connection info mai 20 15:31:20 laptop.home bluetoothd[791]: connect error: Host is down (112) --- Additional comment from Didier G on 2019-05-20 13:45:30 UTC --- In previous message please read kernel 5.0.15. Apologizes. --- Additional comment from on 2019-05-21 08:38:18 UTC --- I have probably the same issue as here. My bluetooth mouse stopped working correctly with the recent kernel 5.0.16. I tried with re-pairing it, but it worked only until I have left it not moving for a while. After that, it couldn't reconnect. Everything works ok on kernel 5.0.14. --- Additional comment from Didier G on 2019-05-21 10:42:08 UTC --- I did not take care this bug has been opened for Fedora 28. I my case, this bug occurs with same kernel releases but with Fedora 30. --- Additional comment from on 2019-05-21 11:06:23 UTC --- The same for me. --- Additional comment from Didier G on 2019-05-22 20:47:25 UTC --- Problem with my old BT 2.0 mouse is fixed by kernel 5.1.4 (available on koji at this time). Thanks for your efforts. --- Additional comment from Andrea Santilli on 2019-05-22 21:10:31 UTC --- I can confirm this bug, kernel 5.0.16 shows problems with my bt mice (controller is an Intel N 6235). Anyway, I've tested the patch you can find at https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtmann.org/T/#u and it seems to fix the issue. Tested with 5.0.17 packaged via fedpkg. --- Additional comment from Andrea Santilli on 2019-05-22 21:12:29 UTC --- Oh, I forgot to tell os is a Fedora 30 x86_64 here. --- Additional comment from Alexander Lindqvist on 2019-05-24 06:55:02 UTC --- Same problem here with an HP bluetooth mouse on an Elitebook 745 G5. Bluetooth does not connect with kernel 5.0.16 or 5.0.17 or 5.1.4. 5.0.14 is the last one that works. --- Additional comment from Alex. H. F. on 2019-05-27 11:10:03 UTC --- I have same Problem with Fedora 30 latest Kernel, with following devices: Controller: 0cf3:3005 Qualcomm Atheros Communications AR3011 Bluetooth Mouse: Targus Bluetooth Mouse Model: AMB09US Just as a remark. I got small script to workaround the problem, and get it fastly connected again. Maybe it helps once waiting for a solution. bluetoothctl pair 00:02:76:30:EA:32 bluetoothctl trust 00:02:76:30:EA:32 bluetoothctl connect 00:02:76:30:EA:32 'this is the device address of my mouse A list of device addresses you get issuing: bluetoothctl devices --- Additional comment from Andrea Santilli on 2019-05-27 22:27:45 UTC --- I guess the issue reported by Alex is about a different bug. The bug we're talking about just makes it impossible to pair a bt device that does not make use of an encryption key. It affects cheap devices. You just can't pair them by using bluetoothctl, I already tried that. --- Additional comment from Ben Cotton on 2019-05-28 18:54:50 UTC --- Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This bug was originated on Fedora 28 but I definitely exists on Fedora 30 (and probably on Fedora 29 too).
It's fixed with 5.1.5: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e96e0ce38b
I can confirm it's fixed in version 5.1.5.
No, Will version 5.1.5 be available for Fedora29 as well?
Hi, Will version 5.1.5 be available for Fedora29 too?
I'm sorry, but 5.1.5 in Fedora30 appears to give only a partial fix. Yes, it is possible now to pair the mouse, unlike in 5.0.16. However now, if the mouse is left untouched for a period of five minutes or so, it becomes disconnected and will not reconnect (the gnome-settings panel shows it as disconnected, every now and then it flashes the message, but it never reconnects). I assume it results from the mouse sleeping; it happens independent of whether or not the computer sleeps, for example if I am typing without using the mouse. The only way I have found to get the mouse working again is to delete the mouse connection entirely, and re-pair, which is a pretty painful way of working. I realise that this is a _behaviour_ that has other similar reports, but they must nevertheless be for a different bug, since they were raised for pre-5.0.13 kernels. This mouse worked perfectly under 5.0.13 on Fedora28 (an additional complication is that in the meantime, I had to upgrade from Fedora28 to Fedora30 to get the 5.1.5 fix. So it could be a regression in Fedora30 as against Fedora28, I guess). Practically, I'm not sure whether this should be raised as a separate bug, though I believe it is likely to be a regression in the 5.1.5 fix. Any advice?
Apologies, please ignore my previous comment (I was inadvertently running 5.0.16 while thinking I was running 5.1.5)
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 30 kernel bugs. Fedora 30 has now been rebased to 5.2.9-200.fc30. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 31, and are still experiencing this issue, please change the version to Fedora 31. If you experience different issues, please open a new bug report for those.
The bug was fixed in 5.1.5, as reported above. It hasn't reappeared. It needs to be marked as FIXED, but I don't think I as the originator have the ability to do this. For the reasons described in my original post, I don't have the ability to test it in 5.2.9-200.fc30, but there is no reason to anticipate a regression.