Bug 526142 - On resume from suspend to ram, bluetooth is "disabled" or is not but doesn't work correctly
Summary: On resume from suspend to ram, bluetooth is "disabled" or is not but doesn't ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: bluez
Version: 11
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-29 02:59 UTC by tedtheologian
Modified: 2009-11-06 00:07 UTC (History)
7 users (show)

Fixed In Version: 4.42-9.fc11
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-11-06 00:07:35 UTC


Attachments (Terms of Use)

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.


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