Bug 1534857 - bluez regression: Bluetooth audio fails to reconnect after resume
Summary: bluez regression: Bluetooth audio fails to reconnect after resume
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez   
(Show other bugs)
Version: 27
Hardware: Unspecified Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Don Zickus
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Regression
: 1534406 1534897 1539380 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-01-16 05:57 UTC by Robert Hancock
Modified: 2018-02-14 17:30 UTC (History)
20 users (show)

Fixed In Version: bluez-5.48-2.fc27
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-02-14 17:30:39 UTC
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
hcidump output from headphone connection attempts (184.87 KB, text/plain)
2018-01-16 05:57 UTC, Robert Hancock
no flags Details

Description Robert Hancock 2018-01-16 05:57:42 UTC
Created attachment 1381828 [details]
hcidump output from headphone connection attempts

Description of problem:
After some recent update (I am guessing bluez), I am seeing problems with Bluetooth audio through Clarity HD headphones not reconnecting properly after resuming from suspend. This is on a Dell XPS 13 9360 using Intel 8265 Bluetooth.

Version-Release number of selected component (if applicable):
bluez-5.48-1.fc27.x86_64

How reproducible:
Seems quite reproducible in this setup

Steps to Reproduce:
1. Connect headphones
2. Suspend and resume
3. Try to reconnect headphones

Actual results:
Connection does not re-establish successfully. Turning the headphones on and off and trying to reconnect manually either doesn't connect or doesn't show up as an audio device. It appears that removing and re-pairing is needed for the connection to work.

Expected results:
Bluetooth reconnects normally

Additional info:
Will attach hcidump output from trying to get the headphones reconnected after resume.

Comment 1 Robert Hancock 2018-01-16 06:13:17 UTC
I'm getting this sort of spew in journalctl when trying to reconnect:

Jan 16 00:06:58 xps13 kernel: Bluetooth: Inquiry failed: status 0x0c
Jan 16 00:06:59 xps13 pulseaudio[1701]: [pulseaudio] backend-native.c: Device doesnt exist for /org/bluez/hci0/dev_34_DF_2A_40_F6_4F
Jan 16 00:06:59 xps13 bluetoothd[911]: Headset Voice gateway replied with an error: org.bluez.Error.InvalidArguments, Unable to handle new connection
Jan 16 00:07:00 xps13 pulseaudio[1701]: [pulseaudio] bluez5-util.c: Information about device /org/bluez/hci0/dev_34_DF_2A_40_F6_4F is invalid
Jan 16 00:07:00 xps13 bluetoothd[911]: Endpoint replied with an error: org.bluez.Error.InvalidArguments

Comment 2 Robert Hancock 2018-01-16 06:47:41 UTC
It appears that "systemctl restart bluetooth" after resume usually or always results in things starting to work again. From what little I can interpret from the failing hcidump log, it appears that disconnect requests keep being sent to the device, though I have no idea why.

Comment 3 Robert Hancock 2018-01-16 06:52:42 UTC
I've also confirmed that downgrading to bluez-5.47-2 resolves this problem, so this definitely appears to be a bluez regression.

Comment 4 Jared Ravetch 2018-01-22 05:53:02 UTC
Having the same issue, bluetooth headphones do not reconnect after resume.  Fedora 27 XPS 13 9360 with Intel 8265.  

I see the following in dmesg:

Bluetooth: Inquiry failed: status 0x0c

Running "systemctl restart bluetooth" after resume does work.  Please fix bluez.

Comment 5 Stephen Finucane 2018-01-22 11:18:53 UTC
I'm seeing this issue too. Downgrading resolve it temporarily, at least. Seems there are reports affecting other distros [1].

[1] https://forum.manjaro.org/t/stable-update-2017-12-31-kernels-xorg-server-mesa-compiz-wine-firefox/37372/80

Comment 6 Thomas L. 2018-01-22 19:51:49 UTC
I'm facing the same issue on my Dell XPS 13 9360 with Qualcomm Atheros QCA6174 802.11ac Wireless Network Adapter (rev 32).

Bluetooth works on first boot. After resume from standby my Bluetooth headset keeps connecting and disconnecting. A stable connection cannot be established. 

This is my log:

20:38:36 pulseaudio: [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files
20:38:26 bluetoothd: Headset Voice gateway replied with an error: org.bluez.Error.InvalidArguments, Unable to handle new connection
20:38:26 pulseaudio: [pulseaudio] backend-native.c: Device doesnt exist for /org/bluez/hci0/dev_04_52_C7_63_95_AB
20:38:12 bluetoothd: Headset Voice gateway replied with an error: org.bluez.Error.InvalidArguments, Unable to handle new connection
20:38:12 pulseaudio: [pulseaudio] backend-native.c: Device doesnt exist for /org/bluez/hci0/dev_04_52_C7_63_95_AB
20:37:56 bluetoothd: Headset Voice gateway replied with an error: org.bluez.Error.InvalidArguments, Unable to handle new connection
20:37:56 pulseaudio: [pulseaudio] backend-native.c: Device doesnt exist for /org/bluez/hci0/dev_04_52_C7_63_95_AB
20:37:44 bluetoothd: No matching connection for device
20:37:44 systemd-rfkill: Failed to open device: No such device
20:37:44 bluetoothd: Unable to get io data for Headset Voice gateway: getpeername: Transport endpoint is not connected (107)

I'm using an updated version of Fedora 27. 

After systemctl restart bluetooth.service everything works fine again.

Comment 7 Daniele Viganò 2018-01-23 10:39:39 UTC
I'm also affected by this issue. Fedora 27 on a Dell Latitude E5450 using a pair of Bluetooth headset. It was working fine with F26.

Comment 8 Daniele Viganò 2018-01-23 10:53:32 UTC
I confirm that downgrading to bluez-5.47-2.fc27.x86_64 from bluez-5.48-1.fc27.x86_64 solved (temporarily) the issue.

Comment 9 Alex 2018-01-24 19:27:15 UTC
Having same issue as other users here with different Bluetooth headset, in 2 different laptops (Toshiba and Lenovo).
Issue "fixed" by downgrading to bluez-5.47-2.fc27.x86_64.

Please remove bluez-5.48-1.fc27.x86_64 from the repo, so other users which did not upgrade it yet, will not have problems.

Comment 10 Bastien Nocera 2018-01-25 10:30:15 UTC
(In reply to Alex from comment #9)
> Having same issue as other users here with different Bluetooth headset, in 2
> different laptops (Toshiba and Lenovo).
> Issue "fixed" by downgrading to bluez-5.47-2.fc27.x86_64.
> 
> Please remove bluez-5.48-1.fc27.x86_64 from the repo, so other users which
> did not upgrade it yet, will not have problems.

It's already in stable, so that's not possible.

The course of action at this point would be to figure out whether the problem is caused by a Fedora specific change (I'm guessing that the .service lockdown changes could cause this), and if not, bisecting the upstream version.

Comment 11 Tommi Kyntola 2018-01-26 07:20:10 UTC
Fwiw, the bluetooth panel popup is already different without the usual "available devices". I can connect to the headset from the system settings, but the headphonse say twice "Phone 2 connected" and then immediately "Phone 2 disconnected". But all in all the symptoms are the same in here, i.e. after suspend the bluetooth does not work and a downgrade helps.

This was with Lenovo X1 4th gen and pxc550.

Comment 12 Krasi 2018-01-28 13:01:11 UTC
*** Bug 1539380 has been marked as a duplicate of this bug. ***

Comment 13 Krasi 2018-01-28 13:03:01 UTC
Same on Bose QuiteComfort 35 Bluetooth Headset and  Lenovo P50

bluetoothctl: 5.48
Intel Corporation Wireless 8260 (wifi and bluetooth all in one)

Comment 14 Krasi 2018-01-28 21:32:45 UTC
after downgrading to bluez-5.47 It worked for a while and now I get a different error
Jan 28 21:26:03 lenovo-p50 bluetoothd[23348]: Unable to register device interface for 04:52:C7:0A:45:B8
Jan 28 21:26:03 lenovo-p50 bluetoothd[23348]: Unable to create object for found device 04:52:C7:0A:45:B8

Comment 15 geoff.mcqueen 2018-02-02 06:12:24 UTC
Experiencing the exact same problems as Tommi Kyntola (#11). Also PXC550, but in my case:
Linux version 4.14.14-300.fc27.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 7.2.1 20180116 (Red Hat 7.2.1-7) (GCC)) #1 SMP Fri Jan 19 13:19:54 UTC 2018
Hardware name: Dell Inc. XPS 15 9560/05FFDN, BIOS 1.1.3 01/18/2017
Bluetooth: Core ver 2.22

Comment 16 Robert Hancock 2018-02-03 04:19:35 UTC
Is anything happening to debug this further? From what I've seen here and on the linux-bluetooth list, I haven't seen any responses from anyone who's able to actually debug or help troubleshoot this. I'm also seeing reports elsewhere of people running into this:

https://www.reddit.com/r/Fedora/comments/7txqms/bluetooth_headset_wont_stay_connected/

If there's no help forthcoming on this, maybe someone should just push out an "update" to revert the package to an older version.

Comment 17 Robert Hancock 2018-02-07 05:14:39 UTC
This has been reported upstream here:

https://marc.info/?l=linux-bluetooth&m=151616078627045&w=2

and also reported against SuSE here:

https://bugzilla.suse.com/show_bug.cgi?id=1076898

Vincent Petry reported he did a git bisect and identified this as the first bad commit:

https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=d6e9539e31c6bb5afd39ec6f09c518d232e6345d

Comment 18 Daniele Viganò 2018-02-07 13:23:20 UTC
I tried to build bluez-5.48 just reverting

https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=d6e9539e31c6bb5afd39ec6f09c518d232e6345d

and it looks working fine now on my F27 Dell Latitude with a my-crappy-headset-from-amazon.

If you want to try my build you can get it from here

https://copr.fedorainfracloud.org/coprs/dani/bluez-rhbz1534857/

(use at your own risk, look inside the src.rpm for the patch)

Comment 19 Bastien Nocera 2018-02-09 14:49:28 UTC
*** Bug 1534897 has been marked as a duplicate of this bug. ***

Comment 20 Bastien Nocera 2018-02-09 14:49:34 UTC
*** Bug 1534406 has been marked as a duplicate of this bug. ***

Comment 21 Dominik 'Rathann' Mierzejewski 2018-02-09 14:51:35 UTC
It looks like there's an upstream patch for this applied already:
https://marc.info/?l=linux-bluetooth&m=151801178209679&w=2

Comment 22 Fedora Update System 2018-02-09 15:39:08 UTC
bluez-5.48-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f79adbb3c0

Comment 23 George Sapkin 2018-02-10 12:16:30 UTC
So far looks like bluez-5.48-2.fc27 fixes this on T470.

Comment 24 Tommi Kyntola 2018-02-11 19:41:18 UTC
bluez 5.48-2 seems to fix it for me, too, on a Lenovo X1.

Comment 25 Daniele Viganò 2018-02-12 12:16:21 UTC
bluez-5.48-2.fc27 works for me too on a Dell Latitude E5450

Comment 26 Fedora Update System 2018-02-13 07:58:27 UTC
bluez-5.48-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-f79adbb3c0

Comment 27 George Sapkin 2018-02-13 12:01:09 UTC
I'm still having my headphones connected in HSP/HFP after standby and/or reconnect instead of A2DP. Additionally notification area Bluetooth indicator doesn't pick up correct state after resume: it shows 'off' even though BT is on a device is paired.

Comment 28 Krasi 2018-02-13 12:32:55 UTC
I am on kde with bluedevil as the manager and so far it all works as expected.

Comment 29 Alex 2018-02-14 17:10:19 UTC
Issue is fixed for me as well with 5.48-2.fc27

Comment 30 Fedora Update System 2018-02-14 17:30:39 UTC
bluez-5.48-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.