Bug 526142

Summary:	On resume from suspend to ram, bluetooth is "disabled" or is not but doesn't work correctly
Product:	[Fedora] Fedora	Reporter:	tedtheologian
Component:	bluez	Assignee:	Bastien Nocera <bnocera>
Status:	CLOSED ERRATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	11	CC:	anton, bnocera, casper, dwmw2, marcel, mishu, plautrba
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	4.42-9.fc11	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-11-06 00:07:35 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:

Description tedtheologian 2009-09-29 02:59:23 UTC

Description of problem:
On resume from suspend to ram, gnome-bluetooth will either not work or say bluetooth is disabled.

Sometimes bluetooth service is running, other times it says dead but subsys locked.

Version-Release number of selected component (if applicable):

bluez-4.42


How reproducible:
resume from suspend to ram

Steps to Reproduce:
1.
2.
3.
  
Actual results:
bluetooth doesn't work till reboot

Expected results:
bluetooth works, such as with mouse

Additional info:
usb bt dongle
Bus 006 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

Comment 1 Bastien Nocera 2009-09-29 14:53:39 UTC

If bluetoothd crashes, you'll need to provide a backtrace of the crash for it to be useful.

Comment 2 Arnaud Kleinveld 2009-10-05 07:27:18 UTC

I have the same problem with my broadcom BCM2046B1 usb-hub/bluetooth device.

Bluetooth isn't crashing, it's just not recognising the device. Normally I see a HCI dev 0 registered in my messages log but after resuming it's missing.

Comment 3 Arnaud Kleinveld 2009-10-05 07:50:02 UTC

Additional from previous message I also have a Dell Wireless 365 Bluetooth Module idVendor=413c, idProduct=8160. From my previous message logs that was the active and recognised one

Comment 4 Arnaud Kleinveld 2009-10-12 02:14:23 UTC

After a resume from suspend not all my Dell device are restored, only:

Bus 003 Device 007: ID 413c:8162 Dell Computer Corp. 
Bus 003 Device 006: ID 413c:8161 Dell Computer Corp. 

I can then manually enable the device again with:

hid2hci --method dell -v 413c -p 8162

Comment 5 Casper Biering 2009-11-02 22:44:59 UTC

I can see that bluez-4.42-8.fc11.i586.rpm tries to include a fix for this issue aswell, but it doesnt seem to work.

I have turned on udev debugging using:
udevadm control --log-priority=debug

But couldnt find any mention of the device or "udevadm trigger" command from /lib/udev/rules.d/70-hid2hci.rules in /var/log/messages, after resumeing a S3 sleep.

Also, if I try to run the "udevadm trigger" manually i get the following error:
trigger: unrecognized option '--property-match=HID2HCI_SWITCH=1'

My guess is that /lib/udev/rules.d/70-hid2hci.rules is backported from rawhide, and that it requires a newer udev version.

Are there any plans for fixing this issue in F11, or should we just upgrade to F12? ;)

Comment 6 Bastien Nocera 2009-11-03 00:06:55 UTC

(In reply to comment #5)
> I can see that bluez-4.42-8.fc11.i586.rpm tries to include a fix for this issue
> aswell, but it doesnt seem to work.
> 
> I have turned on udev debugging using:
> udevadm control --log-priority=debug
> 
> But couldnt find any mention of the device or "udevadm trigger" command from
> /lib/udev/rules.d/70-hid2hci.rules in /var/log/messages, after resumeing a S3
> sleep.
> 
> Also, if I try to run the "udevadm trigger" manually i get the following error:
> trigger: unrecognized option '--property-match=HID2HCI_SWITCH=1'
> 
> My guess is that /lib/udev/rules.d/70-hid2hci.rules is backported from rawhide,
> and that it requires a newer udev version.

Sigh. Try with a blunt instrument (say, vi) and remove the unrecognised option. It should work then.

> Are there any plans for fixing this issue in F11, or should we just upgrade to
> F12? ;)  

A good engineer blames his tool, eg. your hardware for which no specs are available, and acts weirdly :)

Comment 7 Casper Biering 2009-11-03 09:15:03 UTC

(In reply to comment #6)
> Sigh. Try with a blunt instrument (say, vi) and remove the unrecognised option.
> It should work then.

Fantastic! It works.

> A good engineer blames his tool, eg. your hardware for which no specs are
> available, and acts weirdly :)  

I agree.

Comment 8 Fedora Update System 2009-11-03 10:03:56 UTC

bluez-4.42-9.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/bluez-4.42-9.fc11

Comment 9 Arnaud Kleinveld 2009-11-03 12:06:53 UTC

bluez-4.42-9 solves this bug for fedora 11 on a Dell Vostro 1220

Comment 10 Fedora Update System 2009-11-04 12:13:07 UTC

bluez-4.42-9.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update bluez'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-10931

Comment 11 Fedora Update System 2009-11-06 00:07:20 UTC

bluez-4.42-9.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.