Created attachment 516110 [details] dmesg from broken session Description of problem: With kernel 2.6.39 or higher, such as the current 2.6.40 kernel from Koji, the Bluetooth service does not always restart properly after a suspend/resume cycle. Specifically, none of my Bluetooth devices (phone, mouse) are listed in the GNOME Shell applet, and I cannot turn Bluetooth on using System Settings. However, if I run systemctl restart bluetooth.service normal service resumes. As far as I'm aware, the kernel is picking up the hardware correctly after resume, as running hciconfig in the "broken" state yields the following: $ hciconfig hci0: Type: BR/EDR Bus: USB BD Address: 00:0D:F0:47:EE:94 ACL MTU: 384:8 SCO MTU: 64:8 UP RUNNING RX bytes:460 acl:0 sco:0 events:18 errors:0 TX bytes:81 acl:0 sco:0 commands:17 errors:0 (I'm filing this under bluez because I know no better, even though it is a change of kernel version that appears to provoke this behaviour. I can't remember seeing it with the 2.6.38 series.) I've attached the dmesg and grep luetoo /var/log/messages from a broken session. Version-Release number of selected component (if applicable): dbus-1.4.6-4.fc15.x86_64 systemd-26-8.fc15.x86_64 kernel-2.6.40-4.fc15.x86_64 gnome-shell-3.0.2-4.fc15.x86_64 bluez-libs-4.87-7.fc15.x86_64 bluez-4.87-7.fc15.x86_64
Created attachment 516111 [details] Output of grep luetoo /var/log/messages
Still happens with kernel-2.6.40.3-0.fc15.x86_64. Hardware is 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode).
Looks like I have this (or a similar) problem here too. Hardware is a Dell mini 10v hciconfig gives: hci0: Type: BR/EDR Bus: USB BD Address: 00:25:56:E7:7F:50 ACL MTU: 1021:8 SCO MTU: 64:1 UP RUNNING PSCAN RX bytes:844 acl:0 sco:0 events:38 errors:0 TX bytes:1144 acl:0 sco:0 commands:38 errors:0 The device seems to be (from lsusb -v): Bus 004 Device 002: ID 413c:02b0 Dell Computer Corp. (...) iProduct 2 BCM2046 Bluetooth Device Kernel version: 2.6.40.3-0.fc15.i686.PAE #1 SMP Tue Aug 16 04:17:30 UTC 2011 i686 i686 i386 GNU/Linux
For the moment I'm working around this by adding a hook that does systemctl restart bluetooth.service in /usr/lib64/pm-utils/sleep.d/ .
I did the same thing, only in /etc/pm/sleep.d/ ;-) So the question is, is the problem somewhere in the bluetooth stack itself, or is it a missing default restart hook in the power management system?
Thanks, James and Michael. Knowing to do the hook is just as good as fixing the bug for my purposes.
Could you show your pm scripts? I have added the hook as well, but bluetooth doesn't work reliably anyway. Thanks
(In reply to comment #7) > Could you show your pm scripts? I have added the hook as well, but bluetooth > doesn't work reliably anyway. I created a file /usr/lib64/pm-utils/sleep.d/99bluez-restart (lib instead of lib64 on 32-bit systems) with +x permissions containing #!/bin/sh . "${PM_FUNCTIONS}" case "$1" in resume|thaw) systemctl restart bluetooth.service ;; *) exit $NA ;; esac
*** Bug 725639 has been marked as a duplicate of this bug. ***
Any further progress on this? Still present in Fedora 16. Even with the workaround of Comment 8, it still happens intermittently (1 in 8 suspend/resume cycles, perhaps).
Created attachment 576741 [details] dmesg from broken session, kernel 3.3.1-3.fc16.x86_64 Still present with: bluez-4.96-3.fc16.x86_64 kernel-3.3.1-3.fc16.x86_64 udev-173-3.fc16.x86_64 xorg-x11-drv-evdev-2.6.99.901-7.20120118git9d9c9870c.fc16.x86_64 More recent dmesg attached. Some interesting messages there like power_supply hid-00:12:A1:68:7D:2C-battery: driver failed to report `capacity' property: -5 (The MAC is the mouse.) This now appears to be further complicated by a bug in the X input layer that results in it ignoring the Bluetooth mouse; this will be reported as a separate bug.
I'm also seeing this in the 32-bit version, FWIW.
*** Bug 704723 has been marked as a duplicate of this bug. ***
Probably related: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/824144 and I'm seeing this in Fedora 17. I posted some /var/log/messages errors I found in bug #716509 (which is probably a duplicate of this one).
I'm currently seeing effects of this bug with BlueProximity (Fedora 16) screen lock tool. After suspend / wakeup BlueProximity repeatedly tries to re-pair with Nokia mobile and fails. Phone shows repeated pin request and connection failed messages and, unable to go into low power mode, phone battery drains much faster than usual. Toggling bluetooth off then on in the laptop top bar restores previous valid pairing, BlueProximity shows connected and phone goes back to sleep. BlueProximity tooltip message while problem is happening show the following 3 messages running in repeated sequence: standard: Detected distance 2; Current State: active; Status: No connection found, trying to establish one... standard: Detected distance 0; Current State: active; Status: Running... standard: Detected distance 255; Current State: active; Status: No connection found, trying to establish one... Once bluetooth has been toggled the message is stable with: standard: Detected distance 0; Current State: active; Status: Running... While the problem is present, /var/log/messages shows a slow repeat of: Jun 15 08:34:03 hostname bluetoothd[1239]: Unable to find matching adapter Jun 15 08:34:03 hostname bluetoothd[1239]: bluetoothd[1239]: Unable to find matching adapter
*** This bug has been marked as a duplicate of bug 753617 ***
(In reply to comment #16) > > *** This bug has been marked as a duplicate of bug 753617 *** How odd. The symptoms appear entirely different: this has to do with a failure to resume the bluetooth service, 753617 has to do with an inability to transfer files with a running bluetooth service.