Bluetooth Hibernate Service - Intel 8260

A4orce84 · 13 January 2022 12:21

System Information:

System:
  Kernel: 5.15.12-1-MANJARO x86_64 bits: 64 compiler: gcc v: 11.1.0
    parameters: BOOT_IMAGE=/boot/vmlinuz-5.15-x86_64
    root=UUID=501de8bc-72f3-4eb8-8dd8-eb0381f16ebc ro
    resume=UUID=2314cba6-fa6e-443b-8fc2-de4d6ad99ffe apparmor=1
    security=apparmor udev.log_priority=3
  Desktop: GNOME 41.2 tk: GTK 3.24.31 wm: gnome-shell dm: GDM 41.0
    Distro: Manjaro Linux base: Arch Linux
Machine:
  Type: Laptop System: Dell product: XPS 13 9350 v: N/A
    serial: <superuser required> Chassis: type: 9 serial: <superuser required>
  Mobo: Dell model: 076F9T v: A00 serial: <superuser required> UEFI: Dell
    v: 1.13.0 date: 02/10/2020
Battery:
  ID-1: BAT0 charge: 20.1 Wh (81.0%) condition: 24.8/57.5 Wh (43.1%)
    volts: 7.6 min: 7.6 model: SMP DELL JHXPY53 type: Li-poly serial: <filter>
    status: Discharging
CPU:
  Info: model: Intel Core i5-6200U bits: 64 type: MT MCP arch: Skylake
    family: 6 model-id: 0x4E (78) stepping: 3 microcode: 0xEA
  Topology: cpus: 1x cores: 2 tpc: 2 threads: 4 smt: enabled cache:
    L1: 128 KiB desc: d-2x32 KiB; i-2x32 KiB L2: 512 KiB desc: 2x256 KiB
    L3: 3 MiB desc: 1x3 MiB
  Speed (MHz): avg: 2542 high: 2692 min/max: 400/2800 scaling:
    driver: intel_pstate governor: powersave cores: 1: 2610 2: 2495 3: 2692
    4: 2371 bogomips: 19204
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities:
  Type: itlb_multihit status: KVM: VMX disabled
  Type: l1tf
    mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable
  Type: mds mitigation: Clear CPU buffers; SMT vulnerable
  Type: meltdown mitigation: PTI
  Type: spec_store_bypass
    mitigation: Speculative Store Bypass disabled via prctl and seccomp
  Type: spectre_v1
    mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2 mitigation: Full generic retpoline, IBPB: conditional,
    IBRS_FW, STIBP: conditional, RSB filling
  Type: srbds mitigation: Microcode
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: Intel Skylake GT2 [HD Graphics 520] vendor: Dell driver: i915
    v: kernel bus-ID: 00:02.0 chip-ID: 8086:1916 class-ID: 0300
  Device-2: Microdia Integrated Webcam HD type: USB driver: uvcvideo
    bus-ID: 1-5:3 chip-ID: 0c45:670c class-ID: 0e02
  Display: wayland server: X.org 1.21.1.2 compositor: gnome-shell driver:
    loaded: intel unloaded: modesetting alternate: fbdev,vesa display-ID: 0
    resolution: <missing: xdpyinfo>
  Message: Unable to show advanced data. Required tool glxinfo missing.
Audio:
  Device-1: Intel Sunrise Point-LP HD Audio vendor: Dell
    driver: snd_hda_intel v: kernel alternate: snd_soc_skl bus-ID: 00:1f.3
    chip-ID: 8086:9d70 class-ID: 0403
  Sound Server-1: ALSA v: k5.15.12-1-MANJARO running: yes
  Sound Server-2: JACK v: 1.9.19 running: no
  Sound Server-3: PulseAudio v: 15.0 running: no
  Sound Server-4: PipeWire v: 0.3.42 running: yes
Network:
  Device-1: Intel Wireless 8260 driver: iwlwifi v: kernel bus-ID: 3a:00.0
    chip-ID: 8086:24f3 class-ID: 0280
  IF: wlp58s0 state: up mac: <filter>
Bluetooth:
  Device-1: Intel Bluetooth wireless interface type: USB driver: btusb v: 0.8
    bus-ID: 1-3:2 chip-ID: 8087:0a2b class-ID: e001
  Report: rfkill ID: hci0 rfk-id: 9 state: up address: see --recommends
Drives:
  Local Storage: total: 238.47 GiB used: 33.96 GiB (14.2%)
  SMART Message: Required tool smartctl not installed. Check --recommends
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: PM951 NVMe 256GB
    size: 238.47 GiB block-size: physical: 512 B logical: 512 B
    speed: 31.6 Gb/s lanes: 4 type: SSD serial: <filter> rev: BXV77D0Q
    temp: 34.9 C scheme: GPT
Partition:
  ID-1: / raw-size: 79 GiB size: 77.26 GiB (97.80%) used: 23.1 GiB (29.9%)
    fs: ext4 dev: /dev/nvme0n1p6 maj-min: 259:6
  ID-2: /boot/efi raw-size: 100 MiB size: 96 MiB (96.00%)
    used: 26.6 MiB (27.7%) fs: vfat dev: /dev/nvme0n1p2 maj-min: 259:2
  ID-3: /home raw-size: 80 GiB size: 78.24 GiB (97.81%)
    used: 9.81 GiB (12.5%) fs: ext4 dev: /dev/nvme0n1p5 maj-min: 259:5
Swap:
  Kernel: swappiness: 10 (default 60) cache-pressure: 75 (default 100)
  ID-1: swap-1 type: partition size: 3.84 GiB used: 1.03 GiB (26.7%)
    priority: -2 dev: /dev/nvme0n1p7 maj-min: 259:7
Sensors:
  System Temperatures: cpu: 37.0 C pch: 32.0 C mobo: 26.0 C sodimm: SODIMM C
  Fan Speeds (RPM): cpu: 0
Info:
  Processes: 327 Uptime: 1d 13h 47m wakeups: 15 Memory: 7.63 GiB
  used: 3.27 GiB (42.8%) Init: systemd v: 250 tool: systemctl Compilers:
  gcc: 11.1.0 clang: 13.0.0 Packages: pacman: 1497 lib: 444 flatpak: 0
  Shell: Zsh v: 5.8 running-in: gnome-terminal inxi: 3.3.11

Hello,

Full-disclosure I am using Manjaro but I actually received help on these forums 2 years ago from @tbg. I made this post as a ‘sequel’ to the one I created on these forums previously:

@tbg - If you look above, you helped me with some Bluetooth issues I had with my XPS-13 laptop by creating a custom Bluetooth service. Well, I recently rediscovered your post, and I have the same laptop that I use, so I decided to follow your advice and steps you laid out, specifically here:

The Problem:
Let me start with saying everything works when I do a fresh boot into Manjaro! Bluetooth works from the start, and I do not have to run that command to ‘restart’ the Bluetooth to get it working properly. Things also appear to be working correctly when resuming from standby.

The issue is when I resume from hibernate. It seems that the Bluetooth fails to ‘turn on’ and I have to run the command to get things working again:

CLI Command:

nmcli networking off; sudo rmmod btusb; sleep 2; sudo modprobe btusb; nmcli networking on

After running this, everything works properly again.

Question:
The service you had me create fixed the issue on a fresh boot. Is there something else I need to create service wise when resuming from hibernation?

This is the last piece to my Bluetooth puzzle. Once this is resolved, it will be fully working without any manual CLI commands from the user-perspective (my end) to get things working properly.

Again, I know this isn’t a Garuda specific question. But as I mentioned in my previous post, I have exhausted all Manjaro, Intel, and even a few Linux resources to find a solution to my problem. You are the only one to have helped me in my quest to get this Bluetooth issue resolved.

Thank you in advance for all of your time and help, it is greatly appreciated!

Thanks,
Asif

BluishHumility · 13 January 2022 13:00

There is a known issue with 5.15 affecting Intel bluetooth radios.

https://bugzilla.kernel.org/show_bug.cgi?id=215167#c13

As far as I know, the only "fix" is as you say: on a cold boot (not reboot--full poweroff, wait a few seconds, then boot) the radio picks back up normally.

Hopefully a patch will come down soon. Until then I would either try your luck with an older kernel, or just get in the habit of shutting down the machine between sessions.

A4orce84 · 13 January 2022 15:48

Hi @BluishHumility,

Thanks for your reply. I actually outlined my fix (really a workaround) in my OP with the CLI command I shared. Running that command brings my Bluetooth back to life and I am able to use the radio successfully again without having to restart or modify any kernels.

Also, I read through the bugzilla link you shared, because I wanted to understand if I am hitting this same issue or if I have a separate issue. One of the first comments suggested reloading the kernel module by running the following commands:

# modprobe -r btusb
# modprobe btusb

Surprisingly, I did NOT get a timeout error as the rest of the bugzilla comment showed. Instead, my Bluetooth radio started working again. Screenshot below:

Screenshot:
https://imgur.com/NpmbJRo

So, reloading the kernel using the commands above ALSO fixed my Bluetooth and the radio started working again. I can only deduce that my issue is a separate issue than the bug report you shared and is NOT related.

I am not sure but maybe the custom Bluetooth service I created with the help of @tbg needs to be modified for resuming from hibernate situations vs. fresh boot-ups.

Any additional comments / feedback / etc. would be greatly appreciated. Thanks!

tbg · 13 January 2022 16:36

Yes, suspend/hibernate and startup services will differ as they are triggered by different events.

There should be both bluetooth startup and suspend service examples I’d written in the past on the old archived Manjaro forum if you search there.

However, a bios update or using a new kernel such as linux-mainline may fix your issue rather than simply work around it.

A4orce84 · 13 January 2022 17:03

Hey Mr. @tbg,

Thanks for the reply and I never thanked you for your help originally 2 years ago, so thank you so much sir!!

To reply to your comments, I am using the latest bios with my laptop (XPS 13 9350) currently and the latest non-experimental Linux Kernel (5.15.12-1-MANJARO) with Manjaro Gnome. I would prefer still using the 'bleeding edge' kernels if possible over switching to the 'linux-mainline' kernel. Or maybe I am not understanding your reply correctly if you are suggesting another option.

Doing some digging in the old archived Manjaro forums, maybe are you referring to this post you had made:

So, possibly the best approach is to create another NEW custom bluetooth service for triggered events for starting up the bluetooth service from hibernate? Or is there a way I can leverage the existing one I created for this purpose (that you helped me create in the post from 2 years ago).

Once again thank you for all of your time and help, it is greatly appreciated!

tbg · 13 January 2022 17:17

The linux-mailine kernel contains all the newest kernel updates and is more bleeding edge than the linux kernel that I believe Manjaro uses (things might have changed since my days there.

Yes that old archived Manjaro thread should contain a Bluetooth suspend service.

I am only currently on my cell and I’m expecting a phone in apt from my doctor shortly, so I can’t get too involved on the forum ATM.

tbg · 14 January 2022 02:21

I did some revisions on a service and scripts from my old thread you found and hopefully it will work for you. Unfortunately, I can't test it out personally as Bluetooth is the first thing I disable on any install.

Bluetooth Restart Service

The Bluetooth Restart Service below should hopefully resolve any issues with Bluetooth not working after resuming from suspend/hibernate.

This Bluetooth Restart Service stops both Wifi and Bluetooth prior to suspend/hibernate, and then restarts both Wifi and BT once resumed.

Bluetooth Restart Service

With your preferred text editor create:

/etc/systemd/system/bt-restart.service

bt-restart.service file contents:

# cat /etc/systemd/system/bt-restart.service
# systemctl enable --now bt-restart.service
# systemctl start bt-restart.service
# systemctl stop bt-restart.service
# systemctl disable bt-restart.service
# systemctl status bt-restart.service
# systemctl daemon-reload

[Unit]
Description=Stop/Start BT Pre/Post Suspend/Hibernate
Before=sleep.target
Before=hibernate.target
StopWhenUnneeded=yes

[Service]
User=root
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking off'
ExecStart=/usr/bin/sleep 1
ExecStart=/usr/bin/sudo -E  /usr/local/bin/stop_bt.sh
ExecStop=/usr/bin/sudo -E  /usr/local/bin/start_bt.sh
ExecStop=/usr/bin/sleep 2
ExecStopPost=-/usr/bin/sudo -u $USER /bin/bash -lc 'nmcli networking on'

[Install]
WantedBy=sleep.target
WantedBy=hibernate.target

Then, in whichever text editor program you are using, save the script, (root or sudo authorization required).

Pre-suspend - Stop Bluetooth Script

Create the pre-suspend script to stop Bluetooth.

With your preferred text editor (root or sudo authorization required), create:

/usr/local/bin/stop_bt.sh

Pre-suspend script contents:

#!/bin/bash
#cat /usr/local/bin/stop_bt.sh
#pre-suspend script to stop bluetooth 

set -euo pipefail
IFS=$'\n\t'

VENDOR="8087"
PRODUCT="0a2b"

for DIR in $(find /sys/bus/usb/devices/ -maxdepth 1 -type l); do
  if [[ -f $DIR/idVendor && -f $DIR/idProduct &&
        $(cat $DIR/idVendor) == $VENDOR && $(cat $DIR/idProduct) == $PRODUCT ]]; then
    echo 0 > $DIR/authorized
  fi
done

With root or sudo authorization save the script as /usr/local/bin/stop_bt.sh, and exit your text editor.

Post-Suspend - Start Bluetooth Script

Create the post-suspend script to start Bluetooth.

With a text editor create:

/usr/local/bin/start_bt.sh

Post-suspend script contents:

#!/bin/bash
#cat /usr/local/bin/start_bt.sh
#post-suspend script to start bluetooth 

set -euo pipefail
IFS=$'\n\t'

VENDOR="8087"
PRODUCT="0a2b"

for DIR in $(find /sys/bus/usb/devices/ -maxdepth 1 -type l); do
  if [[ -f $DIR/idVendor && -f $DIR/idProduct &&
        $(cat $DIR/idVendor) == $VENDOR && $(cat $DIR/idProduct) == $PRODUCT ]]; then
    echo 1 > $DIR/authorized
  fi
done

With root or sudo authorization save the script as /usr/local/bin/start_bt.sh, and exit your text editor.

Then, make both scripts executable:

sudo chmod +x /usr/local/bin/stop_bt.sh && sudo chmod +x /usr/local/bin/start_bt.sh

Then enable the bt-restart.service:

systemctl enable --now bt-restart.service

Anyone wishing to stop/start any USB device can easily do so by altering the script and inserting your device's HWID.

You can find the hardware ID of of your Bluetooth device, (or any other USB device) with the lsusb command.

Substitute your own hardware device ID codes for the device that you wish stopped/started - pre/post suspend into both scripts.

The fields for the "VENDOR" and "PRODUCT" codes (found with the lsusb command ) must be substituted in the scripts above.

In the fields shown below, you must substitute/insert your own 4 digit (X2) alphanumeric hardware device ID codes in both scripts.

VENDOR="8087"
PRODUCT="0a2b"

Both "8087"` and "0a2b" must be swapped with your own device's hardware codes, (quotation marks included).

I hope my explanations about the required script modifications is not too confusing to understand.

Let me know how that works out for you, and I appreciated your honesty about the distro you were using (that's why I helped you out).

Good luck, and be sure to give Garuda a test drive (you just may like it).

A4orce84 · 14 January 2022 17:23

Hey @tbg,

First off, thank you again for all of your time and help! I really appreciate it!

Update:
I ended up implementing the first version of your bt-restart.service (non-comprehensive) script, and can officially say after suspending / hibernating my XPS laptop several times, the bluetooth appears to be working correctly each time!

I never thought I would have this laptop (that I have owned since 2016) FULLY working with Linux, but it looks like the day has finally come (wifi, bluetooth, webcam, dual-boot, etc.) I currently have no issues. I've been on this iteration of Manjaro since January 2020, so around 2 years without distro hopping so far. We will see if Garuda will be in my future the next time I want to try something.

Thank you again @tbg, reading through your post in the archived Manjaro forums, it seems like you are using services for a variety of fixes, so you definitely taught me something with your help.

Thanks,
Asif

system · 16 January 2022 17:23

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.