Bug 1175536 - Bluetooth connection is no longer working
Bluetooth connection is no longer working
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
x86-64 openSUSE Tumbleweed
: P5 - None : Normal (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-08-20 12:27 UTC by Aayush Agarwal
Modified: 2022-01-14 14:29 UTC (History)
5 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
duelistgamer: needinfo? (acho)


Attachments
Bluetooth dmesg (13.89 KB, text/x-log)
2020-08-23 07:47 UTC, Aayush Agarwal
Details
Hardware information as output by hwinfo (1.00 MB, text/plain)
2020-08-23 07:48 UTC, Aayush Agarwal
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Aayush Agarwal 2020-08-20 12:27:59 UTC
After updating to the first Tumbleweed snapshot containing kernel 5.8, my bluetooth connection is no longer functioning correctly.

1. On connecting to a bluetooth audio device after booting, the connection is fine.
2. On disconnecting and reconnecting to the same device, the connection doesn't seem to work and the audio device does not indicate that it has received a connection.
3. On wiping all saved bluetooth devices and adding new ones, the search function appears to behave strangely and add ALL bluetooth devices that it is able to detect, not just the one device I want to connect to.
4. It fails to pair any new bluetooth device that I want to connect after this.

My tumbleweed machine is a Thinkpad T460p, configured with an i7 6820HQ CPU.

lspci result:

00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x16) (rev 07)
00:01.2 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor PCIe Controller (x4) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 530 (rev 06)
00:14.0 USB controller: Intel Corporation 100 Series/C230 Series Chipset Family USB 3.0 xHCI Controller (rev 31)
00:14.2 Signal processing controller: Intel Corporation 100 Series/C230 Series Chipset Family Thermal Subsystem (rev 31)
00:16.0 Communication controller: Intel Corporation 100 Series/C230 Series Chipset Family MEI Controller #1 (rev 31)
00:17.0 SATA controller: Intel Corporation HM170/QM170 Chipset SATA Controller [AHCI Mode] (rev 31)
00:1c.0 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #1 (rev f1)
00:1c.4 PCI bridge: Intel Corporation 100 Series/C230 Series Chipset Family PCI Express Root Port #5 (rev f1)
00:1f.0 ISA bridge: Intel Corporation QM170 Chipset LPC/eSPI Controller (rev 31)
00:1f.2 Memory controller: Intel Corporation 100 Series/C230 Series Chipset Family Power Management Controller (rev 31)
00:1f.3 Audio device: Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31)
00:1f.4 SMBus: Intel Corporation 100 Series/C230 Series Chipset Family SMBus (rev 31)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (2) I219-LM (rev 31)
02:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev a2)
03:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)
Comment 1 Takashi Iwai 2020-08-21 07:49:11 UTC
Is this a regression kernel update?  Just boot with the older kernel (choose in GRUB menu) and check whether the problem still persists or not.
Since it looks intermittent, several reboots with the new and the old kernels and test with them would be appreciated.

Also, please give hwinfo output, as well as dmesg outputs; if any, from both working and non-working cases.  Thanks.
Comment 2 Aayush Agarwal 2020-08-23 07:47:11 UTC
Created attachment 840943 [details]
Bluetooth dmesg

Takashi, it seems my original report was inaccurate.

The error persists regardless of which kernel version I am on. dmesg indicates a segmentation fault in bluetoothd.

Pairing new devices also fails. I've attached the dmesg output for kernel 5.8 segmentation fault and kernel 5.7 segmentation fault+failed pairing.

The fault code seems to be identical for both kernels.
Comment 3 Aayush Agarwal 2020-08-23 07:48:28 UTC
Created attachment 840944 [details]
Hardware information as output by hwinfo

Hardware information attached. Hopefully these two are enough, but please let me know if I can provide more info.
Comment 4 Takashi Iwai 2020-08-24 16:53:38 UTC
OK, thanks.
Adding bluez maintainers to Cc.

Seife, Al, there seems something fishy in bluez with the recent kernel.
Comment 5 Al Cho 2020-08-28 09:53:05 UTC
(In reply to Takashi Iwai from comment #4)
> OK, thanks.
> Adding bluez maintainers to Cc.
> 
> Seife, Al, there seems something fishy in bluez with the recent kernel.

ok, but the bt.log is less information.

Aayush, would you please attach logs use "/usr/lib/bluetooth/bluetoothd -d" which reproduce this situation ?
Comment 6 Aayush Agarwal 2020-08-30 16:51:31 UTC
Sorry for the delay; just moved to the 20200826 snapshot. I couldn't find the bluetooth directory in /usr/lib. Has it changed?
Comment 7 Al Cho 2020-08-31 09:00:55 UTC
(In reply to Aayush Agarwal from comment #6)
> Sorry for the delay; just moved to the 20200826 snapshot. I couldn't find
> the bluetooth directory in /usr/lib. Has it changed?

No, it's not, and it's weird ....
You can use "rpm -ql bluez" to find where is it.
Comment 8 Aayush Agarwal 2020-09-01 15:24:51 UTC
(In reply to Al Cho from comment #7)
> (In reply to Aayush Agarwal from comment #6)
> > Sorry for the delay; just moved to the 20200826 snapshot. I couldn't find
> > the bluetooth directory in /usr/lib. Has it changed?
> 
> No, it's not, and it's weird ....
> You can use "rpm -ql bluez" to find where is it.

It seems that bluetooth has been moved to libexec.

On running "/usr/libexec/bluetooth/bluetoothd -d" I am getting:

D-Bus setup failed: Name already in use

Apologies for the very newbie-ish situation, but I am completely unfamiliar with the workings of D-Bus. I don't know how to temporarily remove it and restore it again. I did try some things in https://askubuntu.com/questions/723671/d-bus-setup-failed-name-already-in-use

But I probably got it wrong, because D-Bus still complained that the name was already in use after rfkill block, systemctl stop and /usr/libexec/ -d.
Comment 9 Al Cho 2020-09-03 04:05:57 UTC
(In reply to Aayush Agarwal from comment #8)
> (In reply to Al Cho from comment #7)
> > (In reply to Aayush Agarwal from comment #6)
> > > Sorry for the delay; just moved to the 20200826 snapshot. I couldn't find
> > > the bluetooth directory in /usr/lib. Has it changed?
> > 
> > No, it's not, and it's weird ....
> > You can use "rpm -ql bluez" to find where is it.
> 
> It seems that bluetooth has been moved to libexec.
> 
> On running "/usr/libexec/bluetooth/bluetoothd -d" I am getting:
> 
> D-Bus setup failed: Name already in use
> 
> Apologies for the very newbie-ish situation, but I am completely unfamiliar
> with the workings of D-Bus. I don't know how to temporarily remove it and
> restore it again. I did try some things in
> https://askubuntu.com/questions/723671/d-bus-setup-failed-name-already-in-use
> 
> But I probably got it wrong, because D-Bus still complained that the name
> was already in use after rfkill block, systemctl stop and /usr/libexec/ -d.

Basically you can use "kill <pid>" to kill the process pid and run 
"/usr/libexec/bluetooth/bluetoothd -d" ... that should works.
Comment 10 Aayush Agarwal 2020-09-10 17:12:11 UTC
(In reply to Al Cho from comment #9)
> (In reply to Aayush Agarwal from comment #8)
> > (In reply to Al Cho from comment #7)
> > > (In reply to Aayush Agarwal from comment #6)
> > > > Sorry for the delay; just moved to the 20200826 snapshot. I couldn't find
> > > > the bluetooth directory in /usr/lib. Has it changed?
> > > 
> > > No, it's not, and it's weird ....
> > > You can use "rpm -ql bluez" to find where is it.
> > 
> > It seems that bluetooth has been moved to libexec.
> > 
> > On running "/usr/libexec/bluetooth/bluetoothd -d" I am getting:
> > 
> > D-Bus setup failed: Name already in use
> > 
> > Apologies for the very newbie-ish situation, but I am completely unfamiliar
> > with the workings of D-Bus. I don't know how to temporarily remove it and
> > restore it again. I did try some things in
> > https://askubuntu.com/questions/723671/d-bus-setup-failed-name-already-in-use
> > 
> > But I probably got it wrong, because D-Bus still complained that the name
> > was already in use after rfkill block, systemctl stop and /usr/libexec/ -d.
> 
> Basically you can use "kill <pid>" to kill the process pid and run 
> "/usr/libexec/bluetooth/bluetoothd -d" ... that should works.

If I kill the bluetoothd process, it automatically restarts. This is even after I rfkill block bluetooth and switch it off from the KDE UI.
Comment 11 Aayush Agarwal 2020-11-01 07:23:09 UTC
(In reply to Aayush Agarwal from comment #10)
> (In reply to Al Cho from comment #9)
> > (In reply to Aayush Agarwal from comment #8)
> > > (In reply to Al Cho from comment #7)
> > > > (In reply to Aayush Agarwal from comment #6)
> > > > > Sorry for the delay; just moved to the 20200826 snapshot. I couldn't find
> > > > > the bluetooth directory in /usr/lib. Has it changed?
> > > > 
> > > > No, it's not, and it's weird ....
> > > > You can use "rpm -ql bluez" to find where is it.
> > > 
> > > It seems that bluetooth has been moved to libexec.
> > > 
> > > On running "/usr/libexec/bluetooth/bluetoothd -d" I am getting:
> > > 
> > > D-Bus setup failed: Name already in use
> > > 
> > > Apologies for the very newbie-ish situation, but I am completely unfamiliar
> > > with the workings of D-Bus. I don't know how to temporarily remove it and
> > > restore it again. I did try some things in
> > > https://askubuntu.com/questions/723671/d-bus-setup-failed-name-already-in-use
> > > 
> > > But I probably got it wrong, because D-Bus still complained that the name
> > > was already in use after rfkill block, systemctl stop and /usr/libexec/ -d.
> > 
> > Basically you can use "kill <pid>" to kill the process pid and run 
> > "/usr/libexec/bluetooth/bluetoothd -d" ... that should works.
> 
> If I kill the bluetoothd process, it automatically restarts. This is even
> after I rfkill block bluetooth and switch it off from the KDE UI.

The problem is still present in the latest snapshot. Killing bluethoothd is ineffective because the program automatically restarts. Is there some way to prevent that so that I could run bluetoothd with debugging option flag?

Thank you.
Comment 12 Miroslav Beneš 2022-01-14 14:29:37 UTC
Forgotten for a while. Sorry about that.

Is the issue still present with the latest TW kernel and updated packages?