This was working perfectly on 17.10 but after upgrading to 18.04 yesterday, when the lid is closed the screen turns off but doesn't suspend properly.
I travel around a lot and immediately noticed the heat (and battery draining) when taking it out of the travel case.
I've tried uncommenting these lines in /etc/systemd/logind.conf
HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend
and restarted but didn't make any difference.
I think I managed to figure out what was going on, thanks to these two sources: Dell XPS 13 (9370) ArchLinux Install notes and Arch Linux Forum.
For some reason, the laptop is not going in deep sleep anymore, but rather an s2idle mode which is merely a screen off type of suspend.
To confirm whether this is the case for your system, suspend the laptop using your favorite method (close the lid, hit Fn+End, write pm-suspend in a terminal if you have pm-utils installed, or hit the Windows key type suspend and hit the Enter key).
Wake up from suspend mode and type in a terminal: sudo journalctl | grep "PM: suspend" | tail -2.
If the output is
May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
May 13 20:52:36 mex kernel: PM: suspend exit
Then you are not entering deep sleep.
You can also check cat /sys/power/mem_sleep which should return
[s2idle] deep
which confirms that the default suspend mode is s2idle (since it is highlighted with brackets).
To try a temporary fix, do echo deep > /sys/power/mem_sleep as a root user. Check that it was successful by looking at the output of cat /sys/power/mem_sleep which should be
s2idle [deep]
then suspend the laptop and wake up again. If sudo journalctl | grep "PM: suspend" | tail -2 returns
May 13 18:41:00 mex kernel: PM: suspend entry (deep)
May 13 20:52:36 mex kernel: PM: suspend exit
then the issue should be fixed. You can put your computer to sleep for a couple of hours and check whether the battery drain improved.
To make it permanent, you have to edit your bootloader cmdline. To do so, edit as root user the file /etc/default/grub, by running for example sudo -H gedit /etc/default/grub. Replace the line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
with
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"
and regenerate your grub configuration (run sudo grub-mkconfig -o /boot/grub/grub.cfg).
Try creating /etc/systemd/sleep.conf:
[Sleep]
SuspendMode=
SuspendState=mem
And reboot. This seems to be working for me, although I'm not certain I didn't also get improvement with the /etc/systemd/logind.conf change I did first. In any case, no heat or fan noise is observed while suspended with the lid shut, and it doesn't respond to ping over wifi either, which I had been getting, intermittently, before.
Battery life still goes down while suspended, probably because the working method of suspend is just less efficient than the default, ideal, method that apparently isn't working properly, but it appears better than the default behaviour.
Tried on my XPS 13 9370, I don't know about older models, although it seems likely they'll be similar.
I had tried installing pm-utils and using pm-suspend and that seemed to be suspending pretty effectively, so I wanted to see if I could make systemd-suspend do the same thing.
I looked through the scripts in pm-utils to figure out what it was actually doing, and it looks like, in this situation, it was doing echo -n "mem" > /sys/power/state. So I created the /etc/systemd/sleep.conf file as shown above to match it.
It's not entirely clear what the default behaviour is. The manpage for systemd-sleep.conf says that the distro should include /etc/systemd/sleep.conf with the compiled-in defaults commented out, so you can see this information, but in ubuntu this file is missing. I noticed though that if you cat /sys/power/state you get:
freeze mem
So I'm guessing that this is what it's doing by default. My guess is that freeze may be being accepted, in that it doesn't throw an error, which would otherwise cause systemd to move on to mem, but maybe doesn't actually work properly, or reliably, for complex reasons we seem unable to determine. So just sending mem instead is a hopeful stab at avoiding that and just doing what pm-suspend does.
I suspect the SuspendMode setting is actually superfluous and doesn't do anything anyway. I suspect this because cat /sys/power/disk just gets you:
[disabled]
Am new user, thus unable to comment with an observation, forced to present it as an answer as if I'm super-confident in it! But I think it's working.
The other answers here are excellent, in-depth and well researched.
Unfortunately they didn't work for my particular machine :(
If you have nVidia graphics, there seems to be a fix that is working for a good number of people, helpfully provided by cascagrossa in the answer to this question: Ubuntu 18.04 crashes on resuming from suspend
It is suspected to be a buggy nouveau driver and can sort out suspend issues by adding nouveau.modeset=0 to grub and has been confirmed in the comments for helping fix the issue for others too.
I've got Intel graphics on my problem machine and curiously I've had no suspend problems with Ubuntu or Kubuntu 18.04 on at least 3 other machines (my friend's and my own), so why this particular machine is being such a douche about it is unclear.
I recommend anyone experiencing this sort of issue to follow these steps to help identify the problem:
Do you have nVidia graphics? If so, try the nouveau.modeset=0 grub trick.
Check that suspend works at all. If you are closing the lid and then opening it up later and it's not waking up, it may seem like it's failing to 'resume'.
You should be able to manually select suspend on any desktop but it's slightly hidden in Gnome Shell - you can either longpress the power button from the top right hand menu of the screen, or click that button whilst holding Alt or press the Super key and type in 'suspend'
By selecting suspend you can check that the screen has switched off, the power LED is flashing as it should and you'd expect that any fan running will also stop. If all this happens but then you can't get your machine to waken up then it would appear to be a 'resume' problem rather than a 'suspend' problem.
My issue has been that it's not actually going into suspend and Murray who asked the original question, when asked by collisionTwo to check this, realised the problem was arising when manually suspending too.
In my case (on the one problem laptop), the screen goes blank but the power LED stays on and if the fan is running it continues to run. The machine does not respond to any keypresses, touchpad movement or clicks or power button presses. The only thing that can be done is to shut it down.
I've tried playing music whilst going into suspend (to check that it's not just the screen going blank) but the music stops and the machine has basically seized up.
Try your machine with a Live USB of 18.04 and check if you have similar suspend issues.
This will just confirm that the suspend issues are not to do with any additional programs that you have installed.
In my case I suspected it was because I had installed tlp which might have been interfering with the suspend mode somehow, but the same behaviour occurred with a Live USB of both Ubuntu 18.04 and Kubuntu 18.04
Try out the other two well researched solutions provided here by monty47 and StrangeNoises and see if you get good results.
If none of the solutions are working to resolve your suspend issues on 18.04 then try the accepted answer to this: Ubuntu 18.04 crashes on resuming from suspend
The provided solution by Matalak (who also asked the question) was to use UKUU to try an older 4.14 kernel.
My problem machine had no suspend issues with Ubuntu 17.10 and Kubuntu 17.10, so it makes sense since 17.10 uses the 4.14 kernel. It now suspends fine in both Ubuntu 18.04 and Kubuntu 18.04 using the 4.14 kernel.
If you tried the other solutions and could only fix your suspend issues by going back to a 4.14 kernel, you might be interested in the bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950
It appears to only be affecting a few machines with a specific combination of hardware and can be difficult to identify in amongst other nouveau related problems or s2idle issues.
It seems to be more prevalent for those running a Bay Trail Atom Celeron/Pentium but others have reported a similar issue with other machines.
If you are able to check your kern.log after this failed suspend (i.e once you've had to shut down your machine and restart) you might notice it says PM: suspend entry (deep) and then you have no further entries apart from the many lines of booting up again.
There is currently a patch that seems to resolve the issue.
If you feel like adding your voice to the bug report, it would be interesting to see which particular machines are affected (and check that the patch fixes the issue for everyone).
Also attempting to gather 'Suspend Issues in 18.04' together in this thread: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724
Just want to add an answer to users of Thinkpad X1 Carbon 6th Gen which has a similar symptom i.e. battery drain while suspended which is caused also by not entering deep sleep mode.
This issue is discussed on this thread on Lenovo's forum, in short the X1C6 opted to support Windows Modern Standby. If you read that thread carefully, you would see that although the symptom is shared, the root causes vary greatly between the XPS 13 9370 and the X1C6. e.g. The output of cat /sys/power/mem_sleep on the X1C6 would only be [s2idle] indicating missing support for deep sleep.
The solutions posted so far for this question applies only to the XPS 13, and not to the X1C6. As far as I understand the best solution to the X1C6's suspend mode issue is to apply a DSDT patch first given by Delta Xi, and subsequently updated by PombeirP. This post takes you through how to apply the patch, but make sure you read the post and all of its updates before any actions.
I wrote a gist documenting issues related to the installation of Ubuntu 18.04 on the Thinkpad X1 Carbon 6th Gen including solutions I found about the slow boot issue caused by LVM as well as this deep sleep issue.
I believe this kernel bug is related:
https://bugzilla.kernel.org/show_bug.cgi?id=199689
See comment #3 in particular:
[…] it's actually intentional to be using s2idle on this machine with the latest upstream kernel.
Just to bring this Question to a close (hopefully...), I've just (July 2019) had an update to my 18.04 LTS with HWE which claims to fix this problem specifically for the Dell XPS 13 (including not going into s2idle.)
Went through a lot of the solutions listed and nothing worked for popOS on xps 9560 :(
Until I saw this hilarious fix on dell's website which was taking from an LTT post.
So, my tentative solution that seems to work so far is: toggling certain BIOS settings on and off. I know it sounds downright idiotic, but I swear it seemed to work from what I've tested so far.
Specifically, I either turned settings off and/or selected a different option for a setting, applied it, then set it back and applied it. The settings I toggled back and forth were:
System Configuration > Touchscreen (Toggled Off, then back On)
Power Management > Auto On Time (Switched it to a different option, then back to Disabled)
Power Management > Wake on Dell USB-C Docks (Toggled Off, then On)
Works great now. . . .
I'm using a Lenovo ThinkPad Edge E531 and experienced a similar issue where the machine was unable to enter deep sleep. The behavior was intermittent, and on resume, sometimes caused the touchpad to stop working on the wifi to disconnect.
I tried a dozen or so fixes suggested online, but the only solution that worked for me was installing UKUU and upgrading the kernel to 4.19.11-041911-generic.
FWIW, I've just replaced the battery on my 2016 XPS 13 (9350) with Ubuntu 16.04 and kernél 4.14.12-041412-generic (the machine was setup in early 2016 with 15.10 and a custom kernel then upgraded to 16.04). Before the replacement, the lid put Linux in suspend mode as it should (though if you plugged the PSU in while in suspend, or plugged it out, eg changed the state Linux thought it worked in, it would run extremely slow until a reboot). Anyway, after the replacement (swollen battery), the notebook would reboot to grub when the lid is closed.
Setting power management to "Standard" (from "Advanced") in "Primary battery configuration" in Dell's/AMI's EFI BIOS (which you can bring up by holding Fn-F2 during boot) seems to have solved the problem.
I am using a Dell XPS13 9360 with Linux Mint 19.3. Suspend was working fine until the kernel upgraded to the 5.4 series. I then had the problems outlined above. None of the suggested solutions worked. However downgrading the kernel to 5.3.0-62-generic sorted the problem and suspend now works properly. This is an unsupported kernel so I will try again when a further kernel upgrade becomes available.
If you have nvidia graphics card, this problem can be solved easily.
Just change GRUB_CMDLINE_LINUX="" to GRUB_CMDLINE_LINUX="nouveau.modeset=0"
in /etc/default/grub file then sudo update-grub && reboot.
Also check in app store, you might need to install additional drivers.
If still doesn't solves the problem try this cat /sys/power/mem_sleep.
If it does not print s2idle [deep] then check this for solving.
for those who don't have nvidia graphics, bad luck guys.
As of 2021 it still not solved. The only way to solve the issue is downgrading kernel to 4.14.0-041400-generic which will solve the problem of hanging when lid closed.
Note: I said lid closed because this version doesn't enter suspend mode when lid closed but some how manages to turn off screen & backlight. :) This is the version I am currently using.
You can downgrade kernel by using ukuu tool or by manually compiling source.
For ukuu tool you need to pay money but if you dont want to pay check github releases section & download it from there.
There a issue page that still not closed but I didnt see any reply from devs in 2021.
Some bug detailed information can be found here & here.
My system specs: (lscpu)
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 55
Model name: Intel(R) Pentium(R) CPU N3510 @ 1.99GHz
Thanks to the answer from me47 and if anyone would like have a more dynamic control, e.g. switch to idle when plugged in and deep mode when unplugged, heres how you can do it.
udev to monitor any system event which we will use it to trigger a scriptsudo apt install udev
check plugged in state (note: the last part of the path may vary)
sudo udevadm info --path=/sys/class/power_supply/ACAD
and it should output something like the following:
E: POWER_SUPPLY_NAME=ACAD
E: POWER_SUPPLY_TYPE=Mains
E: POWER_SUPPLY_ONLINE=1
E: SUBSYSTEM=power_supply
/opt/custom-scripts/auto_cycle_sleep_mode.sh, you are free to put the script anywhere you want. Once you created the file, input the following#!/bin/bash
#This script is used to control when to put laptop in idle mode or sleep mode
#after lid closed depending if it is connected to AC or not so it does not require any manual changes
IS_PLUGGED_IN=${1:-0}
MESSAGE=""
if [ $IS_PLUGGED_IN -eq 1 ]
then
MESSAGE="AC Plugged In, switch to idle mode"
echo s2idle > /sys/power/mem_sleep
else
MESSAGE="AC Unplugged, switch to deep sleep mode"
echo deep > /sys/power/mem_sleep
fi
now=date +'%Y-%m-%d %H:%M:%S'
echo "[$now] - $MESSAGE" | sudo tee --append /tmp/udev.log
The above is a simple script which take in a parameter of the plugged in state and echo it to /sys/power/mem_sleep and write log
sudo nano /etc/udev/rules.d/80-local.rules
and input the following
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_NAME}=="ACAD", ENV{POWER_SUPPLY_TYPE}=="Mains", RUN+="/opt/custom-scripts/auto_cycle_sleep_mode.sh %E{POWER_SUPPLY_ONLINE}"
what the script is doing is, filter the event we need, which in this case is the state of POWER_SUPPLY_ONLINE, and we will pass it to our script. if you want to know some basic about udev, here is an introduction to udev: https://opensource.com/article/18/11/udev
sudo service udev restart
[2022-04-16 11:16:48] - AC Unplugged, switch to deep sleep mode
[2022-04-16 11:16:52] - AC Plugged In, switch to idle mode
[2022-04-16 11:22:15] - AC Unplugged, switch to deep sleep mode
[2022-04-16 11:22:23] - AC Plugged In, switch to idle mode
sudo service udev status or tail -f /var/log/syslog