Bug 2274047

Summary: Bluetooth headset partially connects under some circumstances with blues 5.73-3.fc40.x86_64
Product: [Fedora] Fedora Reporter: Martin Jackson <mhjacks>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 40CC: abetakehiko, acaringi, adscvr, airlied, alciregi, awilliam, bskeggs, dtantsur, dwmw2, gopalkrishna.tiwari, hdegoede, hpa, jarod, josef, kernel-maint, linville, masami256, mchehab, pbrobinson, ptalbert, spacewar, steved
Target Milestone: ---Keywords: Desktop, Regression
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: AcceptedFreezeException
Fixed In Version: kernel-6.8.5-201.fc39 kernel-6.8.5-301.fc40 kernel-6.8.5-101.fc38 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-04-13 01:14:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2187795    

Description Martin Jackson 2024-04-08 20:07:19 UTC
Bluetooth device acts connected, but bluez does not show it this way. The device is partially usable but things like mode-switching for conference calls (in the case of this device, which is an audio headset) don't work like they should unless I "manually" connect the device using bluetoothctl such that the device is properly registered.

Reproducible: Always

Steps to Reproduce:
1. Pair headset normally
2. Power headset off
3. Power headset on

It will say it reconnects (from the headset side) but will not show as a connected device in the system tray or in bluetoothctl
Actual Results:  
Device acts connected (can play music through it, and it shows up in the Sound controls in GNOME) but automatic mode switching (i.e. in gmeet, where it switches to the handsfree modes and msbc) is flaky

Expected Results:  
Bluetoothctl and system tray show connected when device says it is connected

The "normal" connection sequence looks like this:

[bluetooth]# connect 14:3F:A6:60:58:58 
Attempting to connect to 14:3F:A6:60:58:58
[CHG] Device 14:3F:A6:60:58:58 Connected: yes
[WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep1 
[WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep2 
[WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3 
[WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep4 
[WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep5 
[WH-1000XM4]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep6 
[WH-1000XM4]# [NEW] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd10 
[WH-1000XM4]# [CHG] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd10 Delay: 0x06a4 (1700)
[WH-1000XM4]# Connection successful
[WH-1000XM4]# [CHG] Device 14:3F:A6:60:58:58 ServicesResolved: yes
[WH-1000XM4]# [CHG] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd10 Volume: 0x002d (45)

When powering off the sequence looks like this:
[WH-1000XM4]# [DEL] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd10 
[WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep1 
[WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep2 
[WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3 
[WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep4 
[WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep5 
[WH-1000XM4]# [DEL] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep6 
[WH-1000XM4]# [CHG] Device 14:3F:A6:60:58:58 ServicesResolved: no
[CHG] Device 14:3F:A6:60:58:58 Connected: no

On reconnection attempt this is the sequence:
[bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep1 
[bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep2 
[bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3 
[bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep4 
[bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep5 
[bluetooth]# [NEW] Endpoint /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep6 
[bluetooth]# [NEW] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd11 
[bluetooth]# [CHG] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd11 Delay: 0x06a4 (1700)
[bluetooth]# [CHG] Transport /org/bluez/hci0/dev_14_3F_A6_60_58_58/sep3/fd11 Volume: 0x002d (45)

Note the lack of Connected: yes

Additionally journalctl -u bluetooth has this:
Apr 08 14:58:06 martjack.imladris.lan bluetoothd[1489]: No matching connection for device
Apr 08 14:59:04 martjack.imladris.lan bluetoothd[1489]: src/profile.c:ext_io_disconnected() Unable to get io data for H>
Apr 08 15:00:00 martjack.imladris.lan bluetoothd[1489]: Authorization request for non-connected device!?

And at this point, the device _acts_ connected, and I can even have bluetoothctl disconnect it, but it doesn't show as connected in the bluetoothctl device list or in the system tray:

[bluetooth]# devices Connected 
[bluetooth]#

I can work around this using bluetoothctl to "manually" connect and disconnect, but I did not have to do this before.

Comment 1 Adam Williamson 2024-04-09 05:36:19 UTC
it'd be best to report this upstream at https://github.com/bluez/bluez/issues . I assume it's yet another thing that broke between 5.72 and 5.73? we really aren't doing much to bluez downstream besides packaging it and backporting some fixes for 5.73 breakage.

Comment 2 Martin Jackson 2024-04-09 13:52:25 UTC
Turns out this is being tracked upstream at https://github.com/bluez/bluez/issues/804. I've linked this report there in case there's additional info that would be helpful.

Comment 3 Peter Robinson 2024-04-10 04:58:21 UTC
This is a kernel problem introduced wit 6.8.2 (which sort of explains why it wasn't seen with the various bluez changes).

Comment 5 Adam Williamson 2024-04-10 17:45:35 UTC
Proposing this as a Final FE just in case we wind up slipping, seems like it'd be nice to get that fix in if we do.

Comment 6 Takehiko Abe 2024-04-11 02:28:14 UTC
*** Bug 2272864 has been marked as a duplicate of this bug. ***

Comment 7 Adam Williamson 2024-04-11 19:19:08 UTC
+4 in https://pagure.io/fedora-qa/blocker-review/issue/1586 , marking accepted FE.

Comment 8 Fedora Update System 2024-04-11 22:02:36 UTC
FEDORA-2024-6d35739db7 (kernel-6.8.5-301.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-6d35739db7

Comment 9 Fedora Update System 2024-04-11 22:04:23 UTC
FEDORA-2024-33a9ea72d1 (kernel-6.8.5-201.fc39) has been submitted as an update to Fedora 39.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-33a9ea72d1

Comment 10 Fedora Update System 2024-04-11 22:05:03 UTC
FEDORA-2024-a56a47ef1b (kernel-6.8.5-101.fc38) has been submitted as an update to Fedora 38.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-a56a47ef1b

Comment 11 Fedora Update System 2024-04-12 02:04:32 UTC
FEDORA-2024-6d35739db7 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-6d35739db7`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-6d35739db7

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

Comment 12 Fedora Update System 2024-04-12 02:33:34 UTC
FEDORA-2024-33a9ea72d1 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-33a9ea72d1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-33a9ea72d1

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

Comment 13 Fedora Update System 2024-04-12 02:41:28 UTC
FEDORA-2024-a56a47ef1b 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-a56a47ef1b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-a56a47ef1b

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

Comment 14 Fedora Update System 2024-04-13 01:14:01 UTC
FEDORA-2024-33a9ea72d1 (kernel-6.8.5-201.fc39) has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 15 Fedora Update System 2024-04-13 03:41:12 UTC
FEDORA-2024-6d35739db7 (kernel-6.8.5-301.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 16 Fedora Update System 2024-04-14 03:08:20 UTC
FEDORA-2024-a56a47ef1b (kernel-6.8.5-101.fc38) has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 17 Peter Robinson 2024-04-15 10:14:38 UTC
*** Bug 2274769 has been marked as a duplicate of this bug. ***

Comment 18 Dmitry Tantsur 2024-04-21 09:52:22 UTC
*** Bug 2274766 has been marked as a duplicate of this bug. ***