Bug 526142 - On resume from suspend to ram, bluetooth is "disabled" or is not but doesn't work correctly
On resume from suspend to ram, bluetooth is "disabled" or is not but doesn't ...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: bluez (Show other bugs)
11
All Linux
low Severity high
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-28 22:59 EDT by tedtheologian
Modified: 2009-11-05 19:07 EST (History)
7 users (show)

See Also:
Fixed In Version: 4.42-9.fc11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-11-05 19:07:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description tedtheologian 2009-09-28 22:59:23 EDT
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 10:53:39 EDT
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 03:27:18 EDT
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 03:50:02 EDT
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-11 22:14:23 EDT
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 17:44:59 EST
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-02 19:06:55 EST
(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 04:15:03 EST
(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 05:03:56 EST
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 07:06:53 EST
bluez-4.42-9 solves this bug for fedora 11 on a Dell Vostro 1220
Comment 10 Fedora Update System 2009-11-04 07:13:07 EST
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-05 19:07:20 EST
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.

Note You need to log in before you can comment on or make changes to this bug.