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):
Seems quite reproducible in this setup
Steps to Reproduce:
1. Connect headphones
2. Suspend and resume
3. Try to reconnect headphones
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.
Bluetooth reconnects normally
Will attach hcidump output from trying to get the headphones reconnected after resume.
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: [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: Headset Voice gateway replied with an error: org.bluez.Error.InvalidArguments, Unable to handle new connection
Jan 16 00:07:00 xps13 pulseaudio: [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: Endpoint replied with an error: org.bluez.Error.InvalidArguments
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.
I've also confirmed that downgrading to bluez-5.47-2 resolves this problem, so this definitely appears to be a bluez regression.
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.
I'm seeing this issue too. Downgrading resolve it temporarily, at least. Seems there are reports affecting other distros .
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.
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.
I confirm that downgrading to bluez-5.47-2.fc27.x86_64 from bluez-5.48-1.fc27.x86_64 solved (temporarily) the issue.
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.
(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.
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.
*** Bug 1539380 has been marked as a duplicate of this bug. ***
Same on Bose QuiteComfort 35 Bluetooth Headset and Lenovo P50
Intel Corporation Wireless 8260 (wifi and bluetooth all in one)
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: Unable to register device interface for 04:52:C7:0A:45:B8
Jan 28 21:26:03 lenovo-p50 bluetoothd: Unable to create object for found device 04:52:C7:0A:45:B8
Experiencing the exact same problems as Tommi Kyntola (#11). Also PXC550, but in my case:
Linux version 4.14.14-300.fc27.x86_64 (firstname.lastname@example.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
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:
If there's no help forthcoming on this, maybe someone should just push out an "update" to revert the package to an older version.
This has been reported upstream here:
and also reported against SuSE here:
Vincent Petry reported he did a git bisect and identified this as the first bad commit:
I tried to build bluez-5.48 just reverting
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
(use at your own risk, look inside the src.rpm for the patch)
*** Bug 1534897 has been marked as a duplicate of this bug. ***
*** Bug 1534406 has been marked as a duplicate of this bug. ***
It looks like there's an upstream patch for this applied already:
bluez-5.48-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f79adbb3c0
So far looks like bluez-5.48-2.fc27 fixes this on T470.
bluez 5.48-2 seems to fix it for me, too, on a Lenovo X1.
bluez-5.48-2.fc27 works for me too on a Dell Latitude E5450
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
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.
I am on kde with bluedevil as the manager and so far it all works as expected.
Issue is fixed for me as well with 5.48-2.fc27
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.