Bluetooth "Connection switch" snaps back by itself until after many tries

[jimav]

Attempting to slide the "Connection" switch in the gui to connect a bluetooth device fails initially -- the switch moves but "snaps back" by itself immediately. Clicking on the switch flashes the "busy" indicator momentarily, but the switch does not move. After a while, connecting succeeds.

I don't know if the mouse input is not recognized until the "Nth" attempt, or else the connection was in-progress all along but the gui was not tracking that correctly.

Please watch the attached video (use vlc).

NOTE: This system is running a non-standard kernel 5.2 in order to circumvent other problems (see bug 1838180).

Again, see the video; there is something wrong with how the GUI communicates with the kernel.

ProblemType: Bug
DistroRelease: Ubuntu 19.04
Package: bluez 5.50-0ubuntu2
Uname: Linux 5.2.0-050200-generic x86_64
ApportVersion: 2.20.10-0ubuntu27.1
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sun Jul 28 22:46:28 2019
InstallationDate: Installed on 2019-02-06 (173 days ago)
InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Release amd64 (20181017.3)
InterestingModules: bluetooth
Lsusb:
 Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
 Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: innotek GmbH VirtualBox
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.2.0-050200-generic root=UUID=75234048-11af-4901-9f89-2c32581f5dd3 ro quiet splash
SourcePackage: bluez
UpgradeStatus: Upgraded to disco on 2019-06-27 (31 days ago)
dmi.bios.date: 12/01/2006
dmi.bios.vendor: innotek GmbH
dmi.bios.version: VirtualBox
dmi.board.name: VirtualBox
dmi.board.vendor: Oracle Corporation
dmi.board.version: 1.2
dmi.chassis.type: 1
dmi.chassis.vendor: Oracle Corporation
dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:
dmi.product.family: Virtual Machine
dmi.product.name: VirtualBox
dmi.product.version: 1.2
dmi.sys.vendor: innotek GmbH
hciconfig:

rfkill:

syslog:
 Jul 28 22:42:11 V-M-Ubuntu-Experimental NetworkManager[828]: <info> [1564378931.7693] Loaded device plugin: NMBluezManager (/usr/lib/x86_64-linux-gnu/NetworkManager/1.16.0/libnm-device-plugin-bluetooth.so)
 Jul 28 22:42:22 V-M-Ubuntu-Experimental systemd[1]: Condition check resulted in Bluetooth service being skipped.

[jimav (james-avera)]

I rebooted before submitting this bug report using ubuntu-bug, so syslog is probably the wrong one. I'll attach the previous one (syslog.1) which I think covers the test demonstrated in the video (and several earlier attempts).

[Daniel van Vugt (vanvugt)]

Thanks for the log file(s). Unfortunately that last one covers several days.

Could you please record the system log for the short period of time while reproducing the bug again?

1. In a terminal window run:

   journalctl -f > newlog.txt

2. Reproduce the bug again.

3. Ctrl-C in the terminal window.

4. Attach the file newlog.txt here.

[jimav (james-avera)]

@Daniel Here you go (newlog_2019_07_29.txt). The log covers only the time while I tried to connect to the headset (took several tries before the switch switched; there are maybe a dozen mouse actions during that time).

There are many message like this:

org.gnome.Shell.desktop[1585]: Window
 manager warning: Overwriting existing binding of keysym 39 with keysym 39 (k
eycode 12).

[jimav (james-avera)]

...and here is a smaller log covering only a single attempt to slide the connection switch to the right (the switch snapped back immediately by itself)

[Daniel van Vugt (vanvugt)]

Thanks. The common factor still seems to be:

Jul 29 12:20:13 V-M-Ubuntu-Experimental bluetoothd[817]: Unable to get Headset Voice gateway SDP record: Device or resource busy
Jul 29 12:20:13 V-M-Ubuntu-Experimental bluetoothd[817]: connect error: Device or resource busy (16)

which is the same error you had in bug 1838180. But obviously this is a different bug since it's happening with kernel 5.2.

I think this bug is basically bluetoothd getting errors from the kernel and unable to comply with the user's requests.

[Daniel van Vugt (vanvugt)]

Hmm, you reported this bug from a virtual machine which doesn't seem to have any Bluetooth hardware, so actually I would expect the switch to not work.

Please submit a new bug from a real machine if that's where you are seeing the problem.

[jimav (james-avera)]

Well, I see the problem also on real hardware, but it's harder to reproduce. In any case, I don't want to install a non-standard kernel there, so it is mixed up with the other problems with the 5.0 kernel.

However, the VM *does* indeed have bluetooth. Virtualbox allows VMs to access any USB device on the host (when enabled). My BT controller is a usb device. For testing I disable BT on the host and later enable the VM to access the BT usb device; it works fine, ie. connects and disconnects as expected (and, yes, even plays music!). All from the VM.

However the GUI problem is most apparent in the VM, running 5.2 kernel.

I don't think using a VM is relevant, except that hardware timing will be different due to i/o instructions being trapped and re-executed on the host. If timing causes a problem, then it probably points to a race condition or similar bug.

Anyway, as I mentioned the same symptom appears less frequently on bare hardware with the 5.0 kernel. I will attached output from journalctl -f for just one "snapback", and for a complete sequence eventually succeeding. Again, tjese were made with the older kernel.

[Daniel van Vugt (vanvugt)]

OK then, in the VM please open a Terminal (Ctrl+Alt+T) and run:

  rfkill > rfkill.txt

and then attach the file 'rfkill.txt' here.

Alternatively run:

  rfkill

and just take a screenshot.

[Daniel van Vugt (vanvugt)]

Please also run this in both the VM and on the host, and send us both outputs:

  lsusb

[Launchpad Janitor (janitor)]

[Expired for bluez (Ubuntu) because there has been no activity for 60 days.]

[Christopher M. Rogers (cajhne)]

Still an issue in the latest Ubuntu 20.04 release.
User winds up having to click the toggle over and over again while it stubbornly snaps back.
Replicated on Many different machines with different hardware.

Is there anyone who can not replicate this bug?

[Daniel van Vugt (vanvugt)]

Christopher, please open a new bug for what you experience by running:

  ubuntu-bug gnome-shell

This bug should stay closed while the original reporter hasn't provided the requested info.