Bug 727106 - Bluetooth service does not reliably resume with kernels >= 2.6.39
Bluetooth service does not reliably resume with kernels >= 2.6.39
Status: CLOSED DUPLICATE of bug 753617
Product: Fedora
Classification: Fedora
Component: bluez (Show other bugs)
16
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
:
: 704723 725639 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-01 06:24 EDT by James
Modified: 2014-09-13 14:57 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-11-22 13:42:36 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)
dmesg from broken session (87.84 KB, text/plain)
2011-08-01 06:24 EDT, James
no flags Details
Output of grep luetoo /var/log/messages (15.18 KB, text/plain)
2011-08-01 06:25 EDT, James
no flags Details
dmesg from broken session, kernel 3.3.1-3.fc16.x86_64 (95.09 KB, text/plain)
2012-04-11 06:44 EDT, James
no flags Details

  None (edit)
Description James 2011-08-01 06:24:39 EDT
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
Comment 1 James 2011-08-01 06:25:13 EDT
Created attachment 516111 [details]
Output of grep luetoo /var/log/messages
Comment 2 James 2011-08-29 00:08:38 EDT
Still happens with kernel-2.6.40.3-0.fc15.x86_64. Hardware is 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode).
Comment 3 Michael Reiger 2011-08-29 23:22:35 EDT
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
Comment 4 James 2011-08-30 06:07:39 EDT
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/ .
Comment 5 Michael Reiger 2011-08-30 19:08:45 EDT
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?
Comment 6 W.C. Epperson 2011-09-06 18:33:22 EDT
Thanks, James and Michael.  Knowing to do the hook is just as good as fixing the bug for my purposes.
Comment 7 Dmitry Ursegov 2011-10-26 15:13:55 EDT
Could you show your pm scripts? I have added the hook as well, but bluetooth doesn't work reliably anyway.

Thanks
Comment 8 James 2011-10-26 15:21:25 EDT
(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
Comment 9 Jacek Pawlyta 2011-11-25 03:46:49 EST
*** Bug 725639 has been marked as a duplicate of this bug. ***
Comment 10 James 2012-03-17 09:10:10 EDT
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).
Comment 11 James 2012-04-11 06:44:05 EDT
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.
Comment 12 Oliver Sampson 2012-05-05 12:48:11 EDT
I'm also seeing this in the 32-bit version, FWIW.
Comment 13 Josh Boyer 2012-06-06 08:56:30 EDT
*** Bug 704723 has been marked as a duplicate of this bug. ***
Comment 14 Garrett Mitchener 2012-06-08 10:01:23 EDT
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).
Comment 15 windchine 2012-06-15 04:08:15 EDT
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
Comment 16 Martin 2012-11-22 13:42:36 EST

*** This bug has been marked as a duplicate of bug 753617 ***
Comment 17 W.C. Epperson 2012-11-22 15:49:19 EST
(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.

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