Bluetooth on Intel Laptop stopped working

English Network/Internet
1

My Laptop is a core i7 with Intel Centrino wireless device.
I have 13.2/KDE installed and have bluez 5.23 (current) bluetooth stack.

Since the early issues with 13.1 and bluez were resolved, my system has started bluetooth reliably and connected to my bluetooth mouse.

Something changed within the past few days, however, and the controller is not powering up on boot.

I see the following, with similar entries in /var/log/messages and dmesg:

# service bluetooth status
bluetooth.service - Bluetooth service
   Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled)
   Active: active (running) since Mon 2015-03-09 09:22:12 EDT; 4min 45s ago
     Docs: man:bluetoothd(8)
 Main PID: 758 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
           `-758 /usr/lib/bluetooth/bluetoothd

Mar 09 09:22:12 HPDV7-Linux bluetoothd[758]: Bluetooth daemon 5.23
Mar 09 09:22:12 HPDV7-Linux bluetoothd[758]: Starting SDP server
Mar 09 09:22:12 HPDV7-Linux bluetoothd[758]: Bluetooth management interface 1.6 initialized
Mar 09 09:22:12 HPDV7-Linux bluetoothd[758]: hci0 Load Connection Parameters failed: Unknown Command (0x01)
Mar 09 09:22:20 HPDV7-Linux.capenet bluetoothd[758]: Failed to set mode: Blocked through rfkill (0x12)
Mar 09 09:22:29 HPDV7-Linux.capenet bluetoothd[758]: Endpoint registered: sender=:1.28 path=/MediaEndpoint/A2DPSource
Mar 09 09:22:29 HPDV7-Linux.capenet bluetoothd[758]: Endpoint registered: sender=:1.28 path=/MediaEndpoint/A2DPSink

So far, Googling the messages has not produced anything useful.

The bluez package has not changed in a while, and kernel update was a while ago as well.
I assume something downloaded in a relatively large batch of updates I did on March 6 are the cause, but reviewing the list in zypp history does not identify a smoking gun.

Anyone else experiencing this?

Any clues as to where to look?

Thanks

2

Hi
The messages show what to check :wink:


Mar 09 09:22:20 HPDV7-Linux.capenet bluetoothd[758]: Failed to set mode: Blocked through rfkill (0x12)

If rfkill isn’t installed, then you need to install it, then check via;


rfkill list

If it’s blocked, you have a switch or a Fn button combination possibly pressed disabling it (sometimes the wireless button uses multi presses for bluetooth and wireless).

You should be able to unblock via the unblock command (run rfkill --help).

3

THANKS!
For anyone who might stumble here and wonder, here is the dialog I used to get running again

# rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
1: hci0: Bluetooth
        Soft blocked: yes
        Hard blocked: no
# rfkill --help
Usage:  rfkill [options] command
Options:
        --version       show version (0.5)
Commands:
        help
        event
        list [IDENTIFIER]
        block IDENTIFIER
        unblock IDENTIFIER
where IDENTIFIER is the index no. of an rfkill switch or one of:
        <idx> all wifi wlan bluetooth uwb ultrawideband wimax wwan gps fm nfc
# rfkill unblock 1:
 rfkill list 1:
1: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

I don’t normally use the F12 wireless control key, but did on Saturday.
It must (silently) cycle thru All on, All off, WiFi On/off, Bluetooth On/off, etc.

4

I have observed since Malcolm’s fix worked that I have to repeat the ‘rfkill unblock’ each time the Laptop resumes from STR, and have sort of concluded that someting in the suspend -resume chain has changed to cause this to happen.

Before I hack in a fix at /etc/pm/sleep.d, I thought I would look about for the root cause, but thus far have found none.

Am I correct that openSuse 13.2 is still using pmutils for sleep and hibernate?
It certainly appears so, /var/log/pm-suspend.log is current each morning from the previous nights sleep-resume cycle,
but the contents reveal noting unusual.
I recall reading quite some time ago that oS would be transitioning to systemd-sleep, but I see no indication in /etc/systemd/ that it is setup.

Thanks for any other thoughts.

5

On Thu 12 Mar 2015 01:16:01 PM CDT, cmcgrath5035 wrote:

I have observed since Malcolm’s fix worked that I have to repeat the
‘rfkill unblock’ each time the Laptop resumes from STR, and have sort of
concluded that someting in the suspend -resume chain has changed to
cause this to happen.

Before I hack in a fix at /etc/pm/sleep.d, I thought I would look about
for the root cause, but thus far have found none.

Am I correct that openSuse 13.2 is still using pmutils for sleep and
hibernate?
It certainly appears so, /var/log/pm-suspend.log is current each morning
from the previous nights sleep-resume cycle,
but the contents reveal noting unusual.
I recall reading quite some time ago that oS would be transitioning to
systemd-sleep, but I see no indication in /etc/systemd/ that it is
setup.

Thanks for any other thoughts.

Hi
There is a systemd service(s) for rfkill;
http://www.freedesktop.org/software/systemd/man/systemd-rfkill@.service.html

I would guess it’s not logging the state and restoring properly, is
this a dual boot machine?

–
Cheers Malcolm °¿° LFCS, SUSE Knowledge Partner (Linux Counter #276890)
SUSE Linux Enterprise Desktop 12 GNOME 3.10.1 Kernel 3.12.36-38-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

6

Ah so, I think I see the problem, but am not sure what a fix would be.
I see:

# service --status-all | grep rfkill
systemd-rfkill@rfkill0.service                         loaded active exited  Load/Save RF Kill Switch Status of rfkill0
systemd-rfkill@rfkill6.service                         loaded active exited  Load/Save RF Kill Switch Status of rfkill6

# rfkill list
0: phy0: Wireless LAN
        Soft blocked: no
        Hard blocked: no
6: hci0: Bluetooth
        Soft blocked: no
        Hard blocked: no

After sleep-resume, hci0: Bluetooth will be ID 7: and “soft blocked yes” again.

It’s not clear what is supposed to be handling bluetooth shutdown and resume.
Looking at the list in /usr/lib/pm-utils/sleep.d, I would probably guess /usr/lib/pm-utils/sleep.d/50rcnetwork, but opening that yields an interesting comment:

cat 50rcnetwork
#!/bin/bash
#
# Prevent lease timing out for networks controlled by ifup/ifdown
# bnc#603291
#
........

# NetworkManager is handled by 55NetworkManager via dbus.
# This script handles only netcontrol alias sysconfig alias ifup.

this script appears to be for legacy ifup, (laptop).

I am running Network Manager, there is no 55NetworkManager script.
I checked YAST, there is no 55NetworkManager file in any RPM That I can see.

I am off to give the udev solution in this item a try.

http://www.alanpinnt.com/2014/08/05/fedora-20-bluetooth-not-powering-on-after-resume-from-suspend/

I don’t want to loose this post, so I’ll be back to report

7

Nope, but then I’m not sure udev runs on resume…

I have to head out for a bit, I’ll try the service approach in the link above later

8

OK, I tried a full reboot and Bluetooth is up and powered after login.

I then tried two STR-resume cycles, both times Bluetooth came back to life with no rfkill activity required.

So the addition of the udev rule highlighted in this post http://www.alanpinnt.com/2014/08/05/fedora-20-bluetooth-not-powering-on-after-resume-from-suspend/ seems to provide a fix.

I still have no idea what triggered this series of events; I loaded 13.2 back in January and it has worked well.

9

Thanks - it solved the problem for me too. Suddenly lost Bluetooth but rfkill fixed it.

/micke

Lenovo x220 Tumbleweed Plasma 5.5.3 Linux 4.0.0-3

10

Hi cmcgrath5035,

I am running Leap 42.1 and your solution worked perfectly for me too. My bluetooth quit working yesterday immediately after doing a vanilla “sudo zypper up” from the stock Leap 42.1 repos which, amongst other things, apparently upgraded my system from Plasma 5.4 to 5.5. So, I searched the forums and found your thread. I have no idea why my bluetooth quit working or whether it had anything to do with the Plasma upgrade or not but your rfkill/udev rule solution fixed it.

Thanks!

Gordon