Bug 2269516

Please actually file some useful details like kernel version, output of relevant HW details (lsusb|grep -i blue) and make/model and things like what devices you are using that have stopped working.

There were no changes to this HW in the release, no Intel bluetooth updates at all, and only iwl9xxx series wifi:

commit 195e420f34c5c029d27ee57c57e3b3a8a164f8c4 (origin/robot/pr-0-1710075315)
Author: Miri Korenblit <miriam.rachel.korenblit>
Date:   Sun Mar 10 14:24:41 2024 +0200

    iwlwifi: update 9000-family firmwares to core85-89
    
    Build number: Core_manual_signed_core85-89
    Revision: 7e3e4b69 (9000, 9260)
    
    Signed-off-by: Miri Korenblit <miriam.rachel.korenblit>

diff --git a/WHENCE b/WHENCE
index 1601d798..724117fd 100644
--- a/WHENCE
+++ b/WHENCE
@@ -824,7 +824,7 @@ File: iwlwifi-9000-pu-b0-jf-b0-38.ucode
 Version: 38.755cfdd8.0
 
 File: iwlwifi-9000-pu-b0-jf-b0-46.ucode
-Version: 46.ff18e32a.0
+Version: 46.7e3e4b69.0
 
 File: iwlwifi-9260-th-b0-jf-b0-34.ucode
 Version: 34.ba501b11.0
@@ -833,7 +833,7 @@ File: iwlwifi-9260-th-b0-jf-b0-38.ucode
 Version: 38.755cfdd8.0
 
 File: iwlwifi-9260-th-b0-jf-b0-46.ucode
-Version: 46.ff18e32a.0
+Version: 46.7e3e4b69.0
 
 File: iwlwifi-cc-a0-50.ucode
 Version: 50.3e391d3e.0
diff --git a/iwlwifi-9000-pu-b0-jf-b0-46.ucode b/iwlwifi-9000-pu-b0-jf-b0-46.ucode
index 9af424f1..c9a75fcc 100644
Binary files a/iwlwifi-9000-pu-b0-jf-b0-46.ucode and b/iwlwifi-9000-pu-b0-jf-b0-46.ucode differ
diff --git a/iwlwifi-9260-th-b0-jf-b0-46.ucode b/iwlwifi-9260-th-b0-jf-b0-46.ucode
index 4c2b25e5..dac525a2 100644
Binary files a/iwlwifi-9260-th-b0-jf-b0-46.ucode and b/iwlwifi-9260-th-b0-jf-b0-46.ucode differ



So I am at an absolute loss as to why this could possibly have regressed (and it's working on my AX200 series devices so we need actual details rather than a single line else the report will just be closed.

Can you also provide output of:

bluetoothctl 
Waiting to connect to bluetoothd...[bluetooth]# Agent registered
[bluetooth]# list
[bluetooth]# show
[bluetooth]# devices

Also hardware make/model inc GPU (there's known problems where some GPUs now interfere with some radio frequencies (yes really!)).

Sorry - I initially only included steps to reproduce and the packages that were involved in triggering "broken" and "working" behaviour. The requested details should all be included below.

But TL;DR: After trying a dozen more times, I was also able to reprodice the issue with the older linux-firmware (which I was not able to after trying a few times yesterday). I'm not sure why the issue appears to manifest more frequently with newer linux-firmware, but it appears to not be *caused* by the linux-firmware update.

Running "systemctl restart bluetooth.service" hangs for about a minute, but then seems to get things into a working state again. So, this indeed looks like an issue with bluez.

I'm moving this to the bluez component then, and will give +1 karma to the linux-firmware update. Thank you for your help!

================================================================================

My hardware is a WiFi 6 / Bluetooth combo on my motherboard (ROG Strix X570-E Gaming). This includes an external antenna, so I really hope interference from the GPU should not be an issue. At any rate, I use an AMD Radeon RX 6600 XT GPU.

I don't even need to connect devices to trigger the broken behaviour - just enabling and disabling the bluetooth interface (rfkill?) causes things to get stuck in a weird state. But the device I was using to test things were Pixel Buds Pro bluetooth earbuds, and they were also the reason I noticed stings stopped working.

================================================================================

"Working" state:

$ uname -r 
6.7.9-200.fc39.x86_64

$ lsusb | grep -i blue 
Bus 001 Device 004: ID 8087:0029 Intel Corp. AX200 Bluetooth

$ bluetoothctl 
Waiting to connect to bluetoothd...[bluetooth]# hci0 new_settings: bondable ssp br/edr le secure-conn 
[bluetooth]# Agent registered
[bluetooth]# [CHG] Controller B0:A4:60:60:13:2C Pairable: yes
[bluetooth]# list
Controller B0:A4:60:60:13:2C neptune [default]
[bluetooth]# show 
Controller B0:A4:60:60:13:2C (public)
	Manufacturer: 0x0002 (2)
	Version: 0x0b (11)
	Name: neptune
	Alias: neptune
	Class: 0x00000000 (0)
	Powered: no
	PowerState: off-blocked
	Discoverable: no
	DiscoverableTimeout: 0x000000b4 (180)
	Pairable: yes
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree Audio Gateway   (0000111f-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
	UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree                 (0000111e-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d0549
	Discovering: no
	Roles: central
	Roles: peripheral
Advertising Features:
	ActiveInstances: 0x00 (0)
	SupportedInstances: 0x0c (12)
	SupportedIncludes: tx-power
	SupportedIncludes: appearance
	SupportedIncludes: local-name
	SupportedSecondaryChannels: 1M
	SupportedSecondaryChannels: 2M
[bluetooth]# devices 
Device 74:74:46:1B:B5:6F Pixel Buds Pro

================================================================================

"Broken" state: I can't reactivate the bluetooth interface (either via UI or "rfkill unblock bluetooth").

$ uname -r 
6.7.9-200.fc39.x86_64

$ lsusb | grep -i blue 
Bus 001 Device 004: ID 8087:0029 Intel Corp. AX200 Bluetooth

$ bluetoothctl 
Waiting to connect to bluetoothd...[bluetooth]# list 
[bluetooth]# show 
No default controller available
[bluetooth]# devices 
No default controller available

quit

This hangs for a while after "Waiting to connect to bluetoothd" and then exits.

The only way to get bluetooth.service out of this unresponsive state seems to be "systemctl restart bluetooth.service".

> I'm moving this to the bluez component then, and will give +1 karma to the
> linux-firmware update. Thank you for your help!

"rpm -q bluez" too please :)

> My hardware is a WiFi 6 / Bluetooth combo on my motherboard (ROG Strix
> X570-E Gaming). This includes an external antenna, so I really hope
> interference from the GPU should not be an issue. At any rate, I use an AMD
> Radeon RX 6600 XT GPU.

These days and with some of the issues I see I no longer rule anything out with the Linux bluetooth stack (you're standing on one foor while testing right? ;-)

> I don't even need to connect devices to trigger the broken behaviour - just
> enabling and disabling the bluetooth interface (rfkill?) causes things to
> get stuck in a weird state. But the device I was using to test things were
> Pixel Buds Pro bluetooth earbuds, and they were also the reason I noticed
> stings stopped working.

OK, this is starting to make some level of sense, the latest bluez update does have a bunch of work around LE Audio which I think, but aren't certain. Will wait to hear which version of bluez.

> $ bluetoothctl 
> Waiting to connect to bluetoothd...[bluetooth]# list 
> [bluetooth]# show 
> No default controller available
> [bluetooth]# devices 
> No default controller available

Is there anything notable in dmesg?

> "rpm -q bluez" too please :)

I had this update installed:
bluez-5.73-1.fc39.x86_64

And now I downgraded to:
bluez-5.72-1.fc39.x86_64

Since I need bluetooth audio to work reliably today.

> Is there anything notable in dmesg?

Not as far as I can tell ... looking at "journalctl -x -b -k" (and "-b -1", "-b -2", "-b -3", for the last four boots) there don't seem to be any kernel messages related to Bluetooth after successful boot and device initialization, except for connection events like these:

kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input30
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input31

> And now I downgraded to:
> bluez-5.72-1.fc39.x86_64
> 
> Since I need bluetooth audio to work reliably today.

And it works with 5.72?

> kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input30
> kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input31

hmm, we have issues with a subset of mice with 5.73 so I wonder whether there's some general regression around some form of input over bluetooth.

I cannot reproduce the "bluetooth.service becomes unresponsive" issue with 5.72.

I tried turning on bluetooth, connecting headphones, disconnecting headphones, turning off bluetooth, over half a dozen times, and I cannot get into the "broken" state.

The only kernel messages are:

kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input30
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input31
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input32
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input33
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input34
kernel: input: Pixel Buds Pro (AVRCP) as /devices/virtual/input/input35

Each line happened a second or two after the earbuds got connected successfully.

I'm not sure why they get assigned to a new input device every time, but this doesn't seem new (happens both with bluez 5.73 and 5.72).

FEDORA-2024-426ecf1fd0 (bluez-5.73-2.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-426ecf1fd0

FEDORA-2024-1ad45eaec7 (bluez-5.73-2.fc38) has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ad45eaec7

FEDORA-2024-f219b6c25c has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f219b6c25c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f219b6c25c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-426ecf1fd0 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-426ecf1fd0`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-426ecf1fd0

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-1ad45eaec7 has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-1ad45eaec7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-1ad45eaec7

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I just realized I can reproduce part of this - the "bluetoothd stuck when disabling BT from GNOME menu" part - with any device I could quickly get my hands on and connect.

Upstream bug with what appears a revert of a single commit that fixes this: https://github.com/bluez/bluez/issues/785 but I'm not aware of the ramifications of that revert.

My adapter is and AMD-branded Mediatek RZ616 on a Framework 13 AMD laptop:

Bus 001 Device 004: ID 0e8d:e616 MediaTek Inc. Wireless_Device

Workstation/GNOME/Wayland on 6.7.10-200.fc39.x86_64.

FEDORA-2024-f219b6c25c (bluez-5.73-2.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Issue was not fixed by this update. Upstream ticket https://github.com/bluez/bluez/issues/785 contains more info why the "fix" was not sufficient.

Proposed as a Blocker and Freeze Exception for 40-final by Fedora user decathorpe using the blocker tracking app because:

 The update to bluez introduced an issue where all interactions with bluetooth hardware (including all GUI related to bluetooth  in GNOME Settings and GNOME Shell) becomes unusable in a common circumstance - disabling the bluetooth interface while there is still a device connected.

Since bluez 5.73, disabling the bluetooth interface (either via GUI or via "rfkill block bluetooth") causes bluetooth.service to enter a busy loop, consuming 100% CPU, and becoming unresponsive. Only restarting bluetooth.service or rebooting recovers the bluetooth interface.

The linked bugzilla contains more information (and links to the upstream bug report). The bluez 5.73-2 build in Fedora includes a path that was supposed to fix this issue, but it did not. The bug is also still not fixed upstream, though there seem to be proposed "complete" fixes in the GitHub issue (either applying more fixes or reverting a problematic commit that was introduced between bluez 5.72 and 5.73).

I don't see a dedicated release criterion for Bluetooth functionality, but I think this bug still qualifies (if not, I will propose it as a FESCo blocker). It causes a default service to lock up in a very common scenario, causing issues with the "rfkill" command and all GNOME GUI for bluetooth settings (including gnome-shell and gnome-settings - which become basically unusable as soon as all actions related to bluetooth start to time out). Currently the only known "fix" to restore bluetooth functionality once bluetooth.service enters this infinite loop is to restart the service on the terminal or to reboot.

The update to bluez 5.73 is only stable in Rawhide and Fedora 40, but is still in "testing" in Fedora 39 and 38 due to -1 or insufficient +1 karma votes.

Any chance of getting a -3 build with the patch from https://github.com/bluez/bluez/issues/785#issuecomment-2023805345 included, to see whether that fixes the problem for good?

(In reply to Bojan Smojver from comment #18)
> Any chance of getting a -3 build with the patch from
> https://github.com/bluez/bluez/issues/785#issuecomment-2023805345 included,
> to see whether that fixes the problem for good?

When it's upstream as a commit that's been accepted sure.

FEDORA-2024-1ad45eaec7 (bluez-5.73-2.fc38) has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

I've created a PR upstream (https://github.com/bluez/bluez/pull/802).  I'll be the first to admit that this is a bit of a blind revert of a single commit, but I have run this for days of active BT use (mouse, headset) and it has completely resolved this issue for me.

Looks like github PRs are not accepted, I'll have to send patches on the bluez list instead.  It'll be a little while until I have time to do this (set up email account for this - no way I'm storing "real" email credentials in plaintext on disk for git send-email, etc).  Given F40's timelines, if maintainers are already set up and have time to shepherd this to the list, feel free to do so.

(not fixed by the f38 update, still present in Fedora [38..=41])

Submitted upstream at https://lore.kernel.org/linux-bluetooth/20240403205252.71978-1-dimitris.on.linux@gmail.com/T/#t

Fedora-specific: I've tested this locally under two package builds, both of which address the issue and don't appear to cause any other problems for me:

- upstream master/HEAD as of today plus the patch above.
- 5.73 with *only* the patch above, ie. I removed device-fix-device_is_connected-checking-for-services.patch from the spec.

Apologies about the spam:  device-fix-device_is_connected-checking-for-services.patch was removed from the package build in *both* cases I described just now.

well, upstream master contains 8060d1208673826665b7297c27aa75003521b52a , which is the same as device-fix-device_is_connected-checking-for-services.patch . so...did something else on upstream master since then fix your case?

did you test 5.73 + device-fix-device_is_connected-checking-for-services.patch + your patch?

thanks!

IIRC I had conflicts combining device-fix-device_is_connected-checking-for-services.patch with my original fix (which was the revert).  So I had tested 5.73 plus just my revert, and also master plus just my revert.  Both worked for me.

I have since gone with a narrower change which doesn't revert all of the changes of 44d3f67277f83983e1e9697eda7b9aeb40ca231d.  Instead, I refactored what used to be the previous "is it connected" logic and use that only in adapter_remove_connection:

https://github.com/bluez/bluez/issues/785#issuecomment-2036076545

I've so far tested this on top of master and it works for me too.  Haven't tested it backported on 5.73 yet.

Upstream has accepted the patch in master.  I've built the package both at master and also at 5.73 with the commit (036583f9bbec8540fbd85b980674aad4916d3093) applied as a patch, and it resolves the issue for me in both instances.

https://koji.fedoraproject.org/koji/taskinfo?taskID=115887481 is a scratch build with Dimitris' patch applied (thanks!); Fabio, can you try it and report back? I'll also see if it happens to fix the Logitech mouse bluetooth slow-scrolling bug, as that one affects me...

Re: slow scrolling, I worked around it before noticing the 100% CPU issue (so no code changes) by blacklisting logitech-hidpp-device:

https://github.com/bluez/bluez/issues/778#issuecomment-2013226643

Crude and avoiding the root cause nodoubt.  Not able to reboot atm to test, but ISTR that the blacklist was still needed even with the CPU patch to restore scrolling sanity.

yeah, I saw that workaround but it'd be nice if this actually *fixes* it. If not I'll use the blocklist :/

Sorry, I can't test this. After upgrading to Fedora 40, my bluetooth hardware stopped working entirely :(

Ah, downgrading to a 6.7 kernel fixed bluetooth stuff. So the 6.8 kernel borks my bluetooth hardware. Yay ...

But from some quick testing after booting the last 6.7 kernel I have, it looks like the linked bluez scratch build fixes the issue.

that other bug is probably https://bugzilla.redhat.com/show_bug.cgi?id=2271784 . kernel 6.8.3 (in testing now) or 6.8.4 (pending) should fix it.

FEDORA-2024-665e28c0f4 (bluez-5.73-3.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-665e28c0f4

FEDORA-2024-8d9c6f3fae (bluez-5.73-3.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-8d9c6f3fae

FEDORA-2024-8d9c6f3fae has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-8d9c6f3fae`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-8d9c6f3fae

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2024-665e28c0f4 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-665e28c0f4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-665e28c0f4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

+3 FE in https://pagure.io/fedora-qa/blocker-review/issue/1547 , marking accepted.

FEDORA-2024-8d9c6f3fae (bluez-5.73-3.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2024-665e28c0f4 (bluez-5.73-3.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

*** Bug 2277199 has been marked as a duplicate of this bug. ***