Bug 2277566

Summary:	bluetoothd spins cpu 92-100% when awakened from hibernate, preventing bluetooth mouse services
Product:	[Fedora] Fedora	Reporter:	TL <bugzilla>
Component:	bluez	Assignee:	Gopal krishna tiwari <gopalkrishna.tiwari>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	38	CC:	dwmw2, gopalkrishna.tiwari, pbrobinson, spacewar
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	bluez-5.75-1.fc38	Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-05-09 01:48:49 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description TL 2024-04-28 02:25:59 UTC

Description of problem:
Upon awakening from a system hibernated state, /usr/libexec/bluetooth/bluetoothd spins at 92-100% cpu, preventing bluetooth devices (mouse) from working, until "kill -9" signal is sent to process

Version-Release number of selected component (if applicable):
bluez-5.73-2.fc38.x86_64

How reproducible:
Awake computer from hibernate state

Steps to Reproduce:
1. Hibernate the computer
2. Awaken computer
3. Observe bluetoothd spinning high cpu, kill -9 bluetoothd process forcing restart of daemon, at which point bluetooth service restored normally

Actual results:
bluetoothd spins cpu at 92-100%, bluetooth mouse inoperative

Expected results:
Normal bluetoothd daemon functioning, bluetooth mouse works

Additional info:

Comment 1 Fedora Update System 2024-04-28 08:28:34 UTC

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

Comment 2 Fedora Update System 2024-05-09 01:48:49 UTC

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