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)
If bluetoothd crashes, you'll need to provide a backtrace of the crash for it to be useful.
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.
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
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
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? ;)
(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 :)
(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.
bluez-4.42-9.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/bluez-4.42-9.fc11
bluez-4.42-9 solves this bug for fedora 11 on a Dell Vostro 1220
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
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.