Created attachment 1525137 [details] journalctl events when bluetooth device successfully pairs in kernels ≤ 4.19.14-300 1. Please describe the problem: HID Bluetooth devices, such as the Socket Mobile S-Series Barcode Scanner, are no longer able to connect in kernel versions 4.19.15-300.fc29 and later. Attempting to connect to paired devices results in an endless loop of the device connecting then disconnecting. Journalctl outputs the following (ad nauseum) during failed connection events: Jan 30 09:49:30 abrt-server[22576]: Failed to open /proc/[pid]/ns directory: Bad file descriptor Jan 30 09:49:30 abrt-server[22576]: Cannot get peer's Namespaces from /proc/21290/ns Jan 30 09:49:46 bluetoothd[21641]: Can't get HIDP connection info Jan 30 09:49:46 bluetoothd[21641]: connect error: Device or resource busy (16) Jan 30 09:49:47 bluetoothd[21641]: Can't get HIDP connection info Jan 30 09:49:47 bluetoothd[21641]: connect error: Device or resource busy (16) Jan 30 09:50:39 bluetoothd[22660]: ioctl_connadd(): File descriptor in bad state (77) Jan 30 09:50:39 bluetoothd[22660]: GLib: Invalid file descriptor Jan 30 10:13:45 bluetoothd[22660]: Can't get HIDP connection info Jan 30 10:13:45 bluetoothd[22660]: ioctl_connadd(): File descriptor in bad state (77) Jan 30 10:13:45 bluetoothd[22660]: GLib: Invalid file descriptor. Jan 30 10:13:53 kernel: Bluetooth: hci0: last event is not cmd complete (0x0f) Issue has been reproduced across two different laptops running identical versions of Fedora: Razer Blade 15" (2018) Lenovo ThinkPad X1 Carbon (Gen 2 w/ eInk touchbar) Reverting to 4.19.14-300.fc29.x86_64 resolves the issue, as does installing the latest 5.0 mainline kernel. The issue persists in all 4.20.x kernels. I've attached a log of what a successful bluetooth pairing looks like in journalctl in working kernels. 2. What is the Version-Release number of the kernel: Tested to be broken on 4.19.15-300.fc29.x86_64, kernel-4.20.4-200.fc29.x86_64, kernel-4.20.3-200.fc29.x86_64
Created attachment 1525138 [details] journalctl events when bluetooth device fails to connect in kernels ≥ 4.19.15
I'm also having the same problems: https://bugzilla.redhat.com/show_bug.cgi?id=1671135 What's the procedure to merge our findings? I'm surprised at the lack of community noise on this problem. Are we the only ones using bluetooth HID devices? Not likely, but sure seems like it.
(In reply to pstrang from comment #2) > I'm also having the same problems: > https://bugzilla.redhat.com/show_bug.cgi?id=1671135 > > What's the procedure to merge our findings? > > I'm surprised at the lack of community noise on this problem. Are we the > only ones using bluetooth HID devices? Not likely, but sure seems like it. I imagine one of the mods will have to merge this. My gut feeling is since standard bluetooth mice & keyboards don't seem to be affected this issue has largely gone unnoticed. Worst part is (aside from hapless kernel updates breaking core functionality every few months) I can't version lock my kernel because chef manages my dnf version lock settings :(
Can someone from bugzilla please respond to this?
We apologize for the inconvenience. There is 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 29 kernel bugs. Fedora XX has now been rebased to 5.0.6 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 30, and are still experiencing this issue, please change the version to Fedora 30. If you experience different issues, please open a new bug report for those.
This is still a problem on the current Kernel I can connect the mouse and use it fine, however if the mouse disconnects, for example I walk away from the machine for 10 minutes, then when I return the mouse continually connects and immediately disconnects if moved (see bluetoothctl output below), I have to manually put the mouse back into pairing mode and reconnect it using bluetoothctl, which while a practical work around is getting to be a PITA. I've included the journalctl output towards the bottom so you can see what's being reported. Any other info required please let me know. Linux machinecode.codesite.non 5.0.19-200.fc29.x86_64 #1 SMP Tue May 28 13:56:29 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux [bluetooth]# connect 00:17:FA:87:D9:45 Attempting to connect to 00:17:FA:87:D9:45 [CHG] Device 00:17:FA:87:D9:45 Connected: yes Connection successful [CHG] Device 00:17:FA:87:D9:45 ServicesResolved: yes [CHG] Device 00:17:FA:87:D9:45 ServicesResolved: no [CHG] Device 00:17:FA:87:D9:45 Connected: no [CHG] Device 00:17:FA:87:D9:45 Connected: yes [CHG] Device 00:17:FA:87:D9:45 Connected: no [CHG] Device 00:17:FA:87:D9:45 Connected: yes [CHG] Device 00:17:FA:87:D9:45 Connected: no [CHG] Device 00:17:FA:87:D9:45 Connected: yes [CHG] Device 00:17:FA:87:D9:45 Connected: no [CHG] Device 00:17:FA:87:D9:45 Connected: yes [CHG] Device 00:17:FA:87:D9:45 Connected: no [CHG] Device 00:17:FA:87:D9:45 Connected: yes [CHG] Device 00:17:FA:87:D9:45 Connected: no [bluetooth]# connect 00:17:FA:87:D9:45 Attempting to connect to 00:17:FA:87:D9:45 [CHG] Device 00:17:FA:87:D9:45 Connected: yes Connection successful [CHG] Device 00:17:FA:87:D9:45 ServicesResolved: yes info 00:17:FA:87:D9:45 Device 00:17:FA:87:D9:45 (public) Name: Microsoft Wireless Laser Mouse 8000 Alias: Microsoft Wireless Laser Mouse 8000 Class: 0x00002580 Icon: input-mouse Paired: yes Trusted: yes Blocked: no Connected: yes LegacyPairing: no UUID: Service Discovery Serve.. (00001000-0000-1000-8000-00805f9b34fb) UUID: Human Interface Device... (00001124-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) Modalias: usb:v045Ep0702d0080 Controller 48:E2:44:F5:00:84 (public) Name: machinecode.codesite.non Alias: machinecode.codesite.non Class: 0x000c010c Powered: yes Discoverable: yes Pairable: yes UUID: Headset AG (00001112-0000-1000-8000-00805f9b34fb) UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb) UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb) UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb) UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb) UUID: Audio Source (0000110a-0000-1000-8000-00805f9b34fb) UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb) UUID: Headset (00001108-0000-1000-8000-00805f9b34fb) Modalias: usb:v1D6Bp0246d0532 Discovering: no >journalctl Jun 11 00:40:27 machinecode.codesite.non kernel: input: Microsoft Wireless Laser Mouse 8000 Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:13/0005:045E:0702.0007/input/input38 Jun 11 00:40:27 D9550.internallan.com kernel: hid-generic 0005:045E:0702.0007: input,hidraw2: BLUETOOTH HID v0.80 Mouse [Microsoft Wireless Laser Mouse 8000] on 48:e2:44:f5:00:84 Jun 11 07:48:15 machinecode.codesite.non bluetoothd[957]: Can't get HIDP connection info Jun 11 07:48:17 machinecode.codesite.non bluetoothd[957]: 00:17:FA:87:D9:45: error updating services: Connection refused (111) Jun 11 07:48:17 machinecode.codesite.non kernel: input: Microsoft Wireless Laser Mouse 8000 Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:13/0005:045E:0702.0008/input/input39 Jun 11 07:48:17 machinecode.codesite.non kernel: input: Microsoft Wireless Laser Mouse 8000 Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:13/0005:045E:0702.0008/input/input40 Jun 11 07:48:17 machinecode.codesite.non kernel: hid-generic 0005:045E:0702.0008: input,hidraw2: BLUETOOTH HID v0.80 Mouse [Microsoft Wireless Laser Mouse 8000] on 48:e2:44:f5:00:84 Jun 11 09:06:23 machinecode.codesite.non bluetoothd[957]: Can't get HIDP connection info Jun 11 09:06:24 machinecode.codesite.non bluetoothd[957]: 00:17:FA:87:D9:45: error updating services: Connection refused (111) Jun 11 09:06:24 machinecode.codesite.non kernel: input: Microsoft Wireless Laser Mouse 8000 Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:13/0005:045E:0702.0009/input/input41 Jun 11 09:06:24 machinecode.codesite.non kernel: input: Microsoft Wireless Laser Mouse 8000 Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:13/0005:045E:0702.0009/input/input42 Jun 11 09:06:24 machinecode.codesite.non kernel: hid-generic 0005:045E:0702.0009: input,hidraw2: BLUETOOTH HID v0.80 Mouse [Microsoft Wireless Laser Mouse 8000] on 48:e2:44:f5:00:84 Jun 11 11:15:49 machinecode.codesite.non bluetoothd[957]: Can't get HIDP connection info Jun 11 11:15:53 machinecode.codesite.non bluetoothd[957]: 00:17:FA:87:D9:45: error updating services: Connection refused (111) Jun 11 11:15:54 v kernel: input: Microsoft Wireless Laser Mouse 8000 Consumer Control as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:12/0005:045E:0702.000A/input/input43 Jun 11 11:15:54 v kernel: input: Microsoft Wireless Laser Mouse 8000 Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:12/0005:045E:0702.000A/input/input44 Jun 11 11:15:54 machinecode.codesite.non kernel: hid-generic 0005:045E:0702.000A: input,hidraw2: BLUETOOTH HID v0.80 Mouse [Microsoft Wireless Laser Mouse 8000] on 48:e2:44:f5:00:84
As mentioned on another bug, you'll want to test this with kernel 5.1.5 at least, and be on the lookout for new "updates-testing" kernel updates in the coming days if that doesn't work for you.
Fixed in 5.1.8-200.fc29.x86_64 thanks
Tested on 5.1.9-300.fc30.x86_64. Still a problem, but I don't see the kernel related kernel messages anymore. Symptoms: Logitec bluetooth travel mouse, connects, works as long as mouse movement doesn't stop. When it sits idle for 2-3 seconds, further mouse movements don't result in pointer motion. However, moving the mouse wheel "wakes" the mouse up and pointer motion is reestablished. I've fiddled around with 'powertop' extensively without any success. I suspect this is driver-related as my bluetooth controller is in the newer wireless network card: 6f:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29) Thank you.
(In reply to pstrang from comment #9) > Tested on 5.1.9-300.fc30.x86_64. Still a problem, but I don't see the kernel > related kernel messages anymore. > > Symptoms: Logitec bluetooth travel mouse, connects, works as long as mouse > movement doesn't stop. When it sits idle for 2-3 seconds, further mouse > movements don't result in pointer motion. However, moving the mouse wheel > "wakes" the mouse up and pointer motion is reestablished. I've fiddled > around with 'powertop' extensively without any success. > > I suspect this is driver-related as my bluetooth controller is in the newer > wireless network card: > 6f:00.0 Network controller: Intel Corporation Wireless-AC 9260 (rev 29) > > Thank you. Can you please try again with 5.1.11, that has a different fix. Also make sure that you have the latest gnome-bluetooth, you need a gnome-bluetooth version >= 3.32.1
[user@host ~]$ rpm -qa |grep -i gnome-bluetooth gnome-bluetooth-libs-devel-3.32.1-2.fc30.x86_64 gnome-bluetooth-3.32.1-2.fc30.x86_64 gnome-bluetooth-libs-3.32.1-2.fc30.x86_64 [user@host ~]$ uname -a Linux host 5.1.11-300.fc30.x86_64 #1 SMP Mon Jun 17 19:33:15 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux Unfortunately, the same behavior. Identical symptoms. Again, I think it's the Intel drivers. An older USB bluetooth adapter connects to the Logitec bluetooth mouse and everything works as expected. Only the built-in bluetooth adapter causes these problems. Another issue, perhaps related. When I'm docked, I have a "046d:c52b Logitech, Inc. Unifying Receiver" with a wireless keyboard and mouse (not bluetooth). The last few kernel releases have slowly progress to worsening behavior. There is a hang in keyboard response. Sometimes 5-10 seconds before keyboard input responds. It's most prevalent when I switch applications and try to type in the other window. The worsening behavior is borderline unusable. I have not noticed a hang in the mouse response, only the keyboard. And it seems to work fine while typing is continuous, but the switching of apps, or pausing, hangs for a few. Even so long that key inputs are lost, not queued. Thanks for your help.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.