XPS 13 9370 no bluetooth after suspend

I wrote a small script to disable and re-enable the bluetooth adapter on sleep/suspend in the systemd hooks. It has been consistently working well for me as I tested across sleep cycles. I am curious to see if it will solve the problem for others here as well!

I put it together into a small make file on github: https://github.com/sankethkatta/dell-xps-ubuntu-bluetooth. If you clone the repo you can simply "sudo make install" to set up the script. There's also an uninstall to clean itself out if you need to.

Well, the new firmware from the windows driver, as described earlier in this thread and in the linked sputnik bug report, has not worked reliably for me. With it, it was better than before, but it still fails eventually. Most of the time it fails with the wifi interface disappearing as well, but not always. I'm going to try the systemd-sleep script suggested in the bug report (before the discussion moved on to the firmware), and if that doesn't work, I try yours. :smileyhappy:

---

@sankethkatta wrote:

I wrote a small script to disable and re-enable the bluetooth adapter on sleep/suspend in the systemd hooks. It has been consistently working well for me as I tested across sleep cycles. I am curious to see if it will solve the problem for others here as well!

I put it together into a small make file on github: https://github.com/sankethkatta/dell-xps-ubuntu-bluetooth. If you clone the repo you can simply "sudo make install" to set up the script. There's also an uninstall to clean itself out if you need to.

---

Sadly this also does not work for me.
Had deactivated bluetooth, set the XPS to sleep, woke it up - bluetooth completely gone again.

Edit: tried again with bluetooth enabled before suspend - same

---

@StrangeNoises wrote:

---

[..] use the kernel parameter btusb.enable_autosuspend=n (actually I'm doing it with "options btusb enable_autosuspend=n" in a file in /etc/modprobe.d); but that kernel option only arrived in 4.16 so I'm running the 4.16 mainline kernel to get it. It appears to be working [..] 

This works best for me at the moment:

newest kernel 4.16
with these kernel parameters: "mem_sleep_default=deep"

because I have TLP installed I set this option instead of the kernel parameter:
USB_BLACKLIST_BTUSB=1

because of the kernel parameter it's finally also going to deep sleep (for example: I can now hear the fans stopping completely when going to sleep - before that the fans went to max and then faded out slowly)

---

@StrangeNoises wrote:

[..] use the kernel parameter btusb.enable_autosuspend=n (actually I'm doing it with "options btusb enable_autosuspend=n" in a file in /etc/modprobe.d); but that kernel option only arrived in 4.16 so I'm running the 4.16 mainline kernel to get it. [..] But this is a lesser workaround, as I understand it, telling the bt adapter not to go to sleep during deep sleep, rather than, presumably preferably, letting it sleep but waking it up thoroughly afterwards, which is the suspend-resume fix.

---

Thank you for the hints.

The following configuration works best for me:

Kernel 4.16.5 or above

Kernel-Parameters: mem_sleep_default=deep

Using TLP with this option: USB_BLACKLIST_BTUSB=1
- if not using TLP try this Kernel parameter: btusb.enable_autosuspend=n

(if I use the systemd sleep hook from this forum that rfkills bluetooth it won't show up for me after waking up)

Finally the device is going to deep sleep. You can hear this when the fans stop running instantly instead of fading out slowly.

EDIT: nope, sleep cycle overnight - BT gone again

Dell changed the mainboard yesterday but today the problem appears again so it's a driver issue.

I called Dell today and they say they won't do anything about it because I ordered a product "without a licence" as they say. I have the developer edition that comes with Ubuntu pre-installed. No Windows seems to mean "no licence".

So they don't give support for Ubuntu powered machines! 

This situation is awfull - I feel ripped.

I have Pro Support and the telephone support let me feel like I bought some illegal black market hardware.

XPS 13 9370 New

I can verify this works even with the new kernel from kali 4.16.0-kali2-amd64

Added this: 

deb http://ppa.launchpad.net/bluetooth/bluez/ubuntu bionic main 

---

@RogerBergling wrote:

XPS 13 9370 New

I can verify this works even with the new kernel from kali 4.16.0-kali2-amd64

Added this: 

deb http://ppa.launchpad.net/bluetooth/bluez/ubuntu bionic main 

 

---

XPS 13 9370 bought February, mainboard replaced last week.

Installed it and I can verify that it sadly does not work (Ubuntu 18.04, Linux 4.16.14-041614-generic).

Hey Guys,

I'm pretty new to the XPS 13, but I've got a 9370 myself, and I haven't experienced this issue. Currently running on Fedora 28 with kernel-4.16.14-300.fc28.x86_64 - can you guys tell me how to reproduce this?

Thanks,
Tim

---

@Venemo wrote:

Hey Guys,

I'm pretty new to the XPS 13, but I've got a 9370 myself, and I haven't experienced this issue. Currently running on Fedora 28 with kernel-4.16.14-300.fc28.x86_64 - can you guys tell me how to reproduce this?

Thanks,
Tim

---

Usually the bluetooth device disappears completely after suspend under Ubuntu 18.04 (and some reports this also on Ubuntu 16.04).

With the new bluez version as suggested above the issue does not occur that frequently but after one workday or so the problem reappears.

In the past a normal reboot worked to get it back. Now I'm using the "mem_sleep_default=deep" kernel parameter to get the laptop into deep sleep with kernel 4.16 (before that there was a high battery drain while suspending) and when the problem appears I have to completely shutdown the machine to get the bluetooth device back.

There is also a bug report at launchpad:

https://bugs.launchpad.net/dell-sputnik/+bug/1766825

The rfkill script earlier in this thread is working well for me on 16.04. Thanks!  I have noticed about 25% of the time, for whatever reason the rfkill unblock bluetooth step doesn't happen automatically, so I just have to run 'sudo rfkill unblock bluetooth' manually from the command line. Not sure why.

The rfkill script sadly does not fix my issue.

Currently running 4.17.0-041700-generic and no joy.

Confirming that this issue is still open as an Arch Linux user with an XPS 13 9370.

Also for bluetooth stops working after resuming from sleep.

The rfkill command doesn't do anything for me, there's no device to block or unblock :

# rfkill 
ID TYPE DEVICE      SOFT      HARD
 1 wlan phy0   unblocked unblocked

I am using kernel version 4.16.13-2-ARCH with mem_sleep_default=deep and bluez version 5.50-3.

Is there a kernel bug report about this issue?

@Venemo wrote:

Is there a kernel bug report about this issue?

---

it does not seem to be a kernel but a firmware issue