Bug 1289863

Also tried:

- X11
- Wayland
- Console

No input.


xinput output (whether or not a bluetooth keyboard is paired):

⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad              	id=14	[slave  pointer  (2)]
⎜   ↳ Logitech Bluetooth Mouse M555b          	id=17	[slave  pointer  (2)]
⎜   ↳ USB keyboard                            	id=11	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ USB keyboard                            	id=10	[slave  keyboard (3)]
    ↳ HP Wireless hotkeys                     	id=15	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ HP WMI hotkeys                          	id=16	[slave  keyboard (3)]
    ↳ Video Bus                               	id=8	[slave  keyboard (3)]
    ↳ HP HD Webcam                            	id=12	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=13	[slave  keyboard (3)]


hcidump for hitting 'a':

> ACL data: handle 9 flags 0x02 dlen 14
    L2CAP(d): cid 0x0041 len 10 [psm 19]
      HIDP: Data: Input report
> ACL data: handle 9 flags 0x02 dlen 14
    L2CAP(d): cid 0x0041 len 10 [psm 19]
      HIDP: Data: Input report

(I assume one is key press, one is key release)

It's working right now.

The fix seemed to have been to delete a bunch of stuff in /var/lib/bluetooth/

All the files in there were OK (by cat-ing), but it's possible there were too many (about 25) and there were two macs for two different bluetooth controllers.

The bluetooth keyboards do now appear in xinput.

Next time it happens I'll try and replicate it by keeping a backup and putting the files back into /var/lib/bluetooth/ to verify.

This is back.

So it's not data in /var/lib/bluetooth/

I still can't for sure say when it will happen.  Switching bluetooth off and on sometimes helps (but not always).  The bluetooth mice do work when all the keyboards stop.

It looks like HIDP is missing sometimes when the pairing happens.


The following happened during a bad pairing (mouse works; keyboard doesn't)

[   30.441937] hid-generic 0005:046D:B009.0003: unknown main item tag 0x0
[   30.442018] input: Logitech Bluetooth Mouse M555b as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:1/0005:046D:B009.0003/input/input25
[   30.442917] hid-generic 0005:046D:B009.0003: input,hidraw2: BLUETOOTH HID v4.19 Mouse [Logitech Bluetooth Mouse M555b] on c4:8e:8f:c1:99:7a
[   40.044447] Bluetooth: hci0 ACL packet for unknown connection handle 2
[   46.357048] Bluetooth: hci0 ACL packet for unknown connection handle 3
[   62.642990] Adjusting tsc more than 11% (8055346 vs 7777428)


The following happens during a good pair:

[  117.729206] hid-generic 0005:046D:B009.0004: unknown main item tag 0x0
[  117.729292] input: Logitech Bluetooth Mouse M555b as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:1/0005:046D:B009.0004/input/input26
[  117.730739] hid-generic 0005:046D:B009.0004: input,hidraw2: BLUETOOTH HID v4.19 Mouse [Logitech Bluetooth Mouse M555b] on c4:8e:8f:c1:99:7a
[  146.209149] Bluetooth: hci0 ACL packet for unknown connection handle 2
[  159.677777] apple 0005:05AC:0256.0005: unknown main item tag 0x0
[  159.677990] input: Apple Wireless Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:3/0005:05AC:0256.0005/input/input27
[  159.678998] apple 0005:05AC:0256.0005: input,hidraw3: BLUETOOTH HID v0.50 Keyboard [Apple Wireless Keyboard] on c4:8e:8f:c1:99:7a

OK, I've been able to trigger it a bit more regularly.

It looks like there's a stale "connected" state that persists.  When un-suspending the laptop sometimes the device works, sometimes it doesn't.

A working wake-up and broken wake-up are attached for an Apple keyboard.  Note how both end in gdm-x-session recording "tagged by udev as: Keyboard".

The broken one starts with:
kernel: Bluetooth: hci0 ACL packet for unknown connection handle 8
and ends with "tagged by udev as: Keyboard".

Note that it ends with the correct udev tag, but no input.

These "unknown connection handle" logs loop with different digits until eventually a working handle # is found; but this can take a long time.

I assume some stale connection handle # is remembered somewhere; but that this # is either in-correct, or the controller and device have a different memory of state.

Created attachment 1105280 [details]
Logs (journalctl) of a bluetooth connection that results in a broken keyboard

Created attachment 1105281 [details]
Logs (journalctl) of a bluetooth connection that results in a working keyboard

Hi,

Does the problem go away after you install the 'bluez-hid2hci' package.  That
package special cases your keyboard.  Install the package and reboot to
have udev pick up the new rule.

Cheers,
Don

I've had that package installed for a long time now, it's still broken.

And it's multiple keyboard manufacturers, not just one.

I think it's related to the built-in Realtek bluetooth device.  It doesn't seem to happen with an external Kensington.  I've been using an external dongle to work around the problem for a while now.  But then why do mice work?

This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 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.

Still a problem in F25

Hi,


I am helping Don here to further diagnose the problem. It would be great if you can share the following debugging logs started in separate console. 

Please share the following once the problem is reproduced and capture in the following logs 

1) btmon output 
2) usbmon output 
3) dmesg out put  
4) journalctl -f --unit=bluetooth output once we have -d option enable (daemon restart is done )

Just one confirmation if their is good pair..  is the keyboard works ever after smoothly or it stops later ?

Gopal...

Created attachment 1265318 [details]
btmon log

Created attachment 1265319 [details]
dmesg output

Created attachment 1265320 [details]
usbmon log

Created attachment 1265321 [details]
journalctl for bluetoothd -d

I've attached the requested logs.


In this case:
1. use a logitech bluetooth keyboard and logitech bluetooth mouse
2. reboot laptop
3. gnome settings shows keyboard and mouse connected
4. keyboard doesn't react
4a. various buttons were pushed, and logged in btmon.
5. at 10:18:27 disconnect the keyboard in gnome settings
6. reconnect the keyboard in gnome-settings
7. keyboard works

Normally after the bluetooth devices connect and work, they remain working until either the device or the laptop loses power.

Edit: 4b. the mouse was working.

_This_ keyboard has a built-in trackpad too.  Trackpad wasn't working.

I am still understanding the reports ...Meanwhile can you please check 

This also might be related to autosuspend, so either a 

usbcore.autosuspend=-1 ( A boot argument)

to disable it and reboot, might work.  Or a 

echo 'on' > /sys/bus/usb/devices/<device>/pwoer/control

might resolve it on a per-device basis.

Gopal...

/sys/bus/usb/devices/<device>/power/control was already on (it's also the wireless card)

My report analysis ...
Still have to dig through  

> HCI Event: Mode Change (0x14) plen 6                         [hci0] 11.915316
        Status: Success (0x00)
        Handle: 2
        Mode: Sniff (0x02)
        Interval: 67.500 msec (0x006c)
= bluetoothd: Can't get HIDP connection info                          16.521632  <<-------------- (1)
@ MGMT Command: Start Discovery (0x0023) plen 1       {0x0001} [hci0] 17.025226
        Address type: 0x07
          BR/EDR
          LE Public
          LE Random
< HCI Command: LE Set Random Address (0x08|0x0005) plen 6      [hci0] 17.025247
        Address: 18:EF:96:0C:0F:27 (Non-Resolvable)
> HCI Event: Command Complete (0x0e) plen 4                    [hci0] 17.026328
      LE Set Random Address (0x08|0x0005) ncmd 2
        Status: Success (0x00)
< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7     [hci0] 17.026353
        Type: Active (0x01)
        Interval: 11.250 msec (0x0012)
        Window: 11.250 msec (0x0012)
        Own address type: Random (0x01)
        Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4                    [hci0] 17.027324
      LE Set Scan Parameters (0x08|0x000b) ncmd 2
        Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2         [hci0] 17.027345
        Scanning: Enabled (0x01)
        Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4                    [hci0] 17.028324
      LE Set Scan Enable (0x08|0x000c) ncmd 2
        Status: Success (0x00)
@ MGMT Event: Command Complete (0x0001) plen 4        {0x0001} [hci0] 17.028348
      Start Discovery (0x0023) plen 1
        Status: Success (0x00)
        Address type: 0x07
          BR/EDR
          LE Public
          LE Random
@ MGMT Event: Discovering (0x0013) plen 2             {0x0002} [hci0] 17.028354
        Address type: 0x07
          BR/EDR
          LE Public
          LE Random
        Discovery: Enabled (0x01)
@ MGMT Event: Discovering (0x0013) plen 2             {0x0001} [hci0] 17.028354
        Address type: 0x07
          BR/EDR
          LE Public
          LE Random
        Discovery: Enabled (0x01)
> HCI Event: LE Meta Event (0x3e) plen 43                      [hci0] 17.646304
      LE Advertising Report (0x02)
        Num reports: 1
        Event type: Connectable undirected - ADV_IND (0x00)
        Address type: Random (0x01)
        Address: D5:48:4B:B5:7F:91 (Static)
        Data length: 31
        Flags: 0x04
          BR/EDR Not Supported
        128-bit Service UUIDs (partial): 1 entry
          Vendor specific (adabfb00-6e7d-4601-bda2-bffaa68956ba)
        Service Data (UUID 0x180a): 120453810000
        RSSI: -88 dBm (0xa8)
> ACL Data RX: Handle 2 flags 0x02 dlen 14                     [hci0] 18.595790
      Channel: 65 len 10 [PSM 0 mode 0] {chan 0}
        a1 01 04 00 00 00 00 00 00 00                    ..........      
> HCI Event: Mode Change (0x14) plen 6                         [hci0] 18.664337
        Status: Success (0x00)
        Handle: 2
        Mode: Active (0x00)
        Interval: 0.000 msec (0x0000)
> HCI Event: Mode Change (0x14) plen 6                         [hci0] 18.709336
        Status: Success (0x00)
        Handle: 2
        Mode: Sniff (0x02)
        Interval: 11.250 msec (0x0012)
> ACL Data RX: Handle 2 flags 0x02 dlen 14                     [hci0] 18.719546
      Channel: 65 len 10 [PSM 0 mode 0] {chan 0}
        a1 01 00 00 00 00 00 00 00 00                    ..........      
> ACL Data RX: Handle 2 flags 0x02 dlen 14                     [hci0] 18.820778
      Channel: 65 len 10 [PSM 0 mode 0] {chan 0}
        a1 01 04 00 00 00 00 00 00 00                    ..........      
> ACL Data RX: Handle 2 flags 0x02 dlen 14                     [hci0] 18.955789
      Channel: 65 len 10 [PSM 0 mode 0] {chan 0}
        a1 01 00 00 00 00 00 00 00 00                    ..........      
@ MGMT Command: Disconnect (0x0014) plen 7            {0x0001} [hci0] 19.026473    <<------------------- Disconnect event 
        BR/EDR Address: 00:07:61:75:60:25 (29530)
< HCI Command: Read Clock Offset (0x01|0x001f) plen 2          [hci0] 19.026492
        Handle: 2
> HCI Event: Command Status (0x0f) plen 4                      [hci0] 19.028327
      Read Clock Offset (0x01|0x001f) ncmd 2
        Status: Success (0x00)
< HCI Command: Disconnect (0x01|0x0006) plen 3                 [hci0] 19.028350
        Handle: 2
        Reason: Remote User Terminated Connection (0x13)  <<-------------------------------------  though before I could see some of ACL RX data .. 


Dec 13 08:34:04 sieve-deschouwer-co-za kernel: Bluetooth: hci0 ACL packet for unknown connection handle 8 <<--------------------------- That's where handle is missing later 
Dec 13 08:34:10 sieve-deschouwer-co-za kernel: apple 0005:05AC:0256.000B: unknown main item tag 0x0
Dec 13 08:34:10 sieve-deschouwer-co-za kernel: input: Apple Wireless Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.0/bluetooth/hci0/hci0:9/0005:05AC:0256.000B/input/input75
Dec 13 08:34:10 sieve-deschouwer-co-za kernel: apple 0005:05AC:0256.000B: input,hidraw0: BLUETOOTH HID v0.50 Keyboard [Apple Wireless Keyboard] on c4:8e:8f:c1:99:7a
Dec 13 08:34:10 sieve-deschouwer-co-za /usr/libexec/gdm-x-session[3841]: (II) config/udev: Adding input device Apple Wireless Keyboard (/dev/input/event16)
Dec 13 08:34:10 sieve-deschouwer-co-za /usr/libexec/gdm-x-session[3841]: (**) Apple Wireless Keyboard: Applying InputClass "evdev keyboard catchall"
Dec 13 08:34:10 sieve-deschouwer-co-za /usr/libexec/gdm-x-session[3841]: (**) Apple Wireless Keyboard: Applying InputClass "libinput keyboard catchall"
Dec 13 08:34:10 sieve-deschouwer-co-za /usr/libexec/gdm-x-session[3841]: (**) Apple Wireless Keyboard: Applying InputClass "system-keyboard"


Mar 22 10:18:20 sieve-deschouwer-co-za bluetoothd[1122]: src/device.c:connect_profiles() /org/bluez/hci0/dev_00_1F_20_35_A8_34 00001101-0000-1000-8000-00805f9b34fb, client :1.62
Mar 22 10:18:24 sieve-deschouwer-co-za bluetoothd[1122]: src/service.c:change_state() 0x55c9b75c9450: device 00:07:61:75:60:25 profile input-hid state changed: connected -> disconnecting (0)
Mar 22 10:18:24 sieve-deschouwer-co-za bluetoothd[1122]: profiles/input/device.c:input_device_disconnect()
Mar 22 10:18:24 sieve-deschouwer-co-za bluetoothd[1122]: Can't get HIDP connection info   <<----------------------------- (1) 
Mar 22 10:18:24 sieve-deschouwer-co-za bluetoothd[1122]: src/service.c:change_state() 0x55c9b75c9450: device 00:07:61:75:60:25 profile input-hid state changed: disconnecting -> disconnected (0)
Mar 22 10:18:25 sieve-deschouwer-co-za bluetoothd[1122]: src/adapter.c:start_discovery_timeout()
Mar 22 10:18:25 sieve-deschouwer-co-za bluetoothd[1122]: src/adapter.c:start_discovery_timeout() adapter->current_discovery_filter == 0

Which kind of looks like failed while reading the HID info .. 

Could see some of the firmware errors as well 

[   18.516521] bluetooth hci0: Direct firmware load for rtl_bt/rtl8723b_config.bin failed with error -2
[   18.516523] Bluetooth: hci0: Failed to load rtl_bt/rtl8723b_config.bin
[   18.516527] Bluetooth: hci0: rtl: loading rtl_bt/rtl8723b_fw.bin
[   18.518174] Bluetooth: hci0: rom_version status=0 version=1
[   18.518181] Bluetooth: cfg_sz 0, total size 22496
[   18.542033] rtlwifi: loading out-of-tree module taints kernel.
[   18.542087] rtlwifi: module verification failed: signature and/or required key missing - tainting kernel

Not sure is the above is playing role here.. 

Gopal..

rtlwifi is from rtlwifi_new, because the stock kernel driver doesn't work with the wifi card.  I'm happy to load a kernel without the tainted module to upload logs.

There is a rtl8723b_fw.bin in /usr/lib/firmware/, and it's still the one from the stock linux-firmware-20161205 package.  I've verified with rpm -V.  The latest firmware I can find in git is the same version, and from december 2015 (but that doesn't mean it's OK...)

I apologise for the intermixed apple keyboard messages.  I'll try and take the batteries out before I create new logs, and my phone.



I can try and re-connect mouse/keyboard separately with 30 seconds to see if there's just too much data up front.  Maybe the chip just can't deal with two re-connects simultaneously.

Created attachment 1266850 [details]
btmon log on Kinsgton Bluetooth

btmon log for a different bluetooth dongle on the same keyboard/mouse

Created attachment 1266851 [details]
btmon log on Kinsgton Bluetooth

Accidentally copied the old btmon.log twice.  This is the real second one

Created attachment 1266852 [details]
dmesg log for Kingston bluetooth dongle

Created attachment 1266853 [details]
journalctl log for kingston dongle

Created attachment 1266854 [details]
usbmon log for kingston dongle

These logs are for a kingston dongle that shows up under lsusb as:
Bus 002 Device 027: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)


This dongle isn't made by Realtek, and doesn't use btrtl or rtlwifi.  It also doesn't use rtl-firmware.

It's harder to trigger the same bug with this dongle, but not impossible.

I had to remove & re-pair the keyboard before it would work.


To remind:
- mouse works of-the-bat
- keyboard (multiple manufacturers) doesn't always pair automatically after suspend

Suspect, not verified:
- it affects the second bluetooth device.  If the keyboard pairs first, the mouse might give problems.

cat /tmp/journalctl.log | grep Host
Mar 28 09:19:08 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
gtiwari@localhost ~ $ 

Looks like some one has to enable the host .

Later further 

 cat /tmp/journalctl.log | grep -e bonding -e Host -e pair
Mar 28 09:19:08 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0x4
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x04
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 4
Mar 28 09:19:18 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0x4
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x04
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 4
Mar 28 09:19:28 sieve-deschouwer-co-za bluetoothd[4033]: 00:07:61:75:60:25: error updating services: Host is down (112)
Mar 28 09:19:38 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:19:38 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:19:38 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:19:45 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:19:45 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:19:45 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:19:51 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe

Mar 28 09:19:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:19:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:19:58 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:19:58 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:19:58 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:05 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:20:05 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:20:05 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:12 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:20:12 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:20:12 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:19 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:20:19 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:20:19 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:26 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe
Mar 28 09:20:26 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Mar 28 09:20:26 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_failed() status 14
Mar 28 09:20:33 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0xe <<------------ bonding successfull 
Mar 28 09:20:45 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:bonding_request_new() Requesting bonding for 00:07:61:75:60:25
Mar 28 09:20:45 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:adapter_bonding_attempt() hci0 bdaddr 00:07:61:75:60:25 type 0 io_cap 0x01
Mar 28 09:20:46 sieve-deschouwer-co-za bluetoothd[4033]: plugins/autopair.c:autopair_pincb() device 00:07:61:75:60:25 (Logitech diNovo Edge) 0x2540
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding 0x55bb70704df0 status 0x00
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() Proceeding with service discovery
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:pair_device_complete() Success (0x00) <<--------------------------------------- pairing done here
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:07:61:75:60:25 type 0 status 0x0 
Mar 28 09:20:51 sieve-deschouwer-co-za bluetoothd[4033]: src/device.c:device_bonding_complete() bonding (nil) status 0x00 <<----------------------- going again for bonding failed 

Even though pairing for the device successful looks like bonding is failing and device is continueouly going for discovering... which intern going to following function 

Which intern also proves by 

> HCI Event: Command Status (0x0f) plen 4                     [hci0] 237.700464
      Authentication Requested (0x01|0x0011) ncmd 1
        Status: Success (0x00)
> HCI Event: Link Key Request (0x17) plen 6                   [hci0] 237.701445
        Address: 00:07:61:75:60:25 (29530)
< HCI Command: Link Key Request Negat.. (0x01|0x000c) plen 6  [hci0] 237.701504
        Address: 00:07:61:75:60:25 (29530)
> HCI Event: Command Complete (0x0e) plen 10                  [hci0] 237.702469
      Link Key Request Negative Reply (0x01|0x000c) ncmd 1 <<-------------------
        Status: Success (0x00)
        Address: 00:07:61:75:60:25 (29530)

Which kind of looks like authentication issue to me..

Can you please try restarting the bluetooth.services by systemctl and see does this help.. Meanwhile I am further going through the reports ..

Gopal..

To be clear:

0. suspend
1. Un-suspend
2. Unlock gui
3. Restart bluetooth.service
4. only then try to connect bluetooth keyboard
...
5. Do this 5 times, and check if the problem persists

Hi, 

I've tried with logitech k380 BT keyboard and apple mouse to reproduce this issue over FC-21 and FC-24  (tried manually as well) with all possible variations. But wasn't successful :( for me the both key board and mouse works all the time 

0. suspend
1. Un-suspend (resume)

Can you tell me more about how you are performing above two steps ?

Gopal...

(In reply to gopal krishna tiwari from comment #29)

> Can you please try restarting the bluetooth.services by systemctl and see
> does this help.. Meanwhile I am further going through the reports ..
> 
> Gopal..


That seems to help.  I've gone a week on the Kingston dongle without a problem.  I'll see about adding a service to suspend.target/post

(In reply to gopal krishna tiwari from comment #32)
> Hi, 
> 
> I've tried with logitech k380 BT keyboard and apple mouse to reproduce this
> issue over FC-21 and FC-24  (tried manually as well) with all possible
> variations. But wasn't successful :( for me the both key board and mouse
> works all the time 
> 
> 0. suspend
> 1. Un-suspend (resume)
> 
> Can you tell me more about how you are performing above two steps ?
> 
> Gopal...

I perform them thusly:

1. suspend
   a. move mouse to top-right corner
   b. hit button, drop down appears
   c. move mouse to power-off
   d. hit "alt" on the keyboard, power-off becomes suspend
   e. click mouse button

2. resume
   a. hit power button on laptop

I usually try to unlock the shell by typing on the bluetooth keyboard.  So that would be the first bluetooth traffic that the OS sees.

There's usually a relatively long time between the two.  At least 30 minutes, and frequently 12 hours.  That may make a difference in the power management on keyboard and mouse.

I wouldn't be surprised if it's hardware dependent.  It's worse on the built-in Realtek 8723be than the Kingston.

(In reply to Berend De Schouwer from comment #33)
> (In reply to gopal krishna tiwari from comment #29)
> 
> > Can you please try restarting the bluetooth.services by systemctl and see
> > does this help.. Meanwhile I am further going through the reports ..
> > 
> > Gopal..
> 
> 
> That seems to help.  I've gone a week on the Kingston dongle without a
> problem.  I'll see about adding a service to suspend.target/post

Great, thanks for the feedback. 

Gopal..

(In reply to Berend De Schouwer from comment #34)
> (In reply to gopal krishna tiwari from comment #32)
> > Hi, 
> > 
> > I've tried with logitech k380 BT keyboard and apple mouse to reproduce this
> > issue over FC-21 and FC-24  (tried manually as well) with all possible
> > variations. But wasn't successful :( for me the both key board and mouse
> > works all the time 
> > 
> > 0. suspend
> > 1. Un-suspend (resume)
> > 
> > Can you tell me more about how you are performing above two steps ?
> > 
> > Gopal...
> 
> I perform them thusly:
> 
> 1. suspend
>    a. move mouse to top-right corner
>    b. hit button, drop down appears
>    c. move mouse to power-off
>    d. hit "alt" on the keyboard, power-off becomes suspend
>    e. click mouse button
> 
> 2. resume
>    a. hit power button on laptop
> 
> I usually try to unlock the shell by typing on the bluetooth keyboard.  So
> that would be the first bluetooth traffic that the OS sees.
> 
> There's usually a relatively long time between the two.  At least 30
> minutes, and frequently 12 hours.  That may make a difference in the power
> management on keyboard and mouse.
> 
> I wouldn't be surprised if it's hardware dependent.  It's worse on the
> built-in Realtek 8723be than the Kingston.

Let me search realtek hardware to verify this.

Gopal...

Problem persists in F26 Beta.

Problem persists in F27 beta

Bluetoothd reports an additional problem:
Oct 06 08:14:30 sieve-deschouwer-co-za bluetoothd[6845]: connect error: Too many levels of symbolic links (40)

/var/lib/bluetooth contains no symbolic links, but it does contain 140 files.  I'm assuming the links are actually somewhere in /sys

Still often gets:
Oct 06 08:14:30 sieve-deschouwer-co-za bluetoothd[6845]: Can't get HIDP connection info


Extra notes: the "too many levels of links" only happens with the Kingston add-on dongle, not the built-in Realtek one.  This also means that so far I haven't gotten the Kingston to pair with anything in F27.

I have managed to get the Realtek to pair, but with the usual frustrations (need to re-pair a few times after un-suspend to get it working.)

This bug is currently reported against a Fedora version which is already unsuported.
I am changing the version to '27', the latest supported release.

Please check whether this bug is still an issue on the '27' release.
If you find this bug not being applicable on this release, please close it.

Still an issue in F29.

Seems better in 4.18.11, worse in 4.18.16

Still gets "Can't get HIDP connection info"

Oct 31 09:27:34 sieve-deschouwer-co-za bluetoothd[1044]: src/device.c:connect_profiles() /org/bluez/hci0/dev_34_88_5D_52_84_0C (all), client :1.765
Oct 31 09:27:34 sieve-deschouwer-co-za bluetoothd[1044]: profiles/input/device.c:input_device_connect()
Oct 31 09:27:34 sieve-deschouwer-co-za bluetoothd[1044]: Can't get HIDP connection info
Oct 31 09:27:34 sieve-deschouwer-co-za bluetoothd[1044]: src/service.c:change_state() 0x561bf2f0bcd0: device 34:88:5D:52:84:0C profile input-hid state changed: disconnected -> connecting (0)

Sometimes gets:

Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 34:88:5D:52:84:0C type 0 status 0x4
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/device.c:device_bonding_complete() bonding (nil) status 0x04
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/device.c:device_bonding_failed() status 4
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/adapter.c:resume_discovery()
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/adapter.c:trigger_start_discovery()
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/adapter.c:cancel_passive_scanning()
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: connect error: Host is down (112)
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/service.c:change_state() 0x561bf2f0bcd0: device 34:88:5D:52:84:0C profile input-hid state changed: connecting -> disconnected (-5)
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/device.c:device_profile_connected() input-hid Input/output error (5)
Oct 31 09:27:25 sieve-deschouwer-co-za bluetoothd[1044]: src/device.c:device_profile_connected() returning response to :1.765
Oct 31 09:27:25 sieve-deschouwer-co-za kernel: Bluetooth: hci0: last event is not cmd complete (0x0f)

Still a problem in F30

(In reply to Berend De Schouwer from comment #41)
> Still a problem in F30

Can confirm that it is still a problem in F30 with Logitech K380 keyboard and CSR BT 4.0 dongle.

From hcidump, I see the following

 < HCI Command: Read Encryption Key Size (0x05|0x0008) plen 2
  0000: 43 00                                             C.
 > ACL data: handle 67 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 17 scid 0x0042
 < ACL data: handle 67 flags 0x00 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0000 scid 0x0042 result 3 status 0
      Connection refused - security block

From Google search, I came across a post(https://linux-bluetooth.vger.kernel.narkive.com/U8xZU5ie/patch-bluetooth-fix-for-security-block-issue#post13), by @Marcel(who is watching this bug report), which mentions that it is due to BT controller being out of spec.

So I tried a $1 BT 3.0 dongle that was lying around and my keyboard works now :-)

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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.