Suspend Issues on Ubuntu 18.04 (and other flavours) – Troubleshooting and Fixes

[perryhelionsemail]

I’ve experienced an issue with suspend on Ubuntu and Kubuntu 18.04, but the issue only occurs on one machine.

Another three different machines I’ve tested had no suspend issues at all and I would have assumed that the fault was with my own crappy laptop, except that suspend was working fine on both Ubuntu and Kubuntu 17.10 and it also turns out that suspend works without issue on 18.04 when using a 4.14 kernel (more on that later).

Whilst searching the forums for a solution to my problem, it has become apparent that although suspend works fine for many people using 18.04 there are a few issues which look similar but have slightly different behaviours and different fixes.

As a quick troubleshooting guide I have outlined a few steps to narrow down where the problem might lie and what might help resolve the issue.

The first thing to check is that suspend actually works at all. It can appear that the machine is failing to resume after going to sleep, but in many cases the machine is failing to enter suspend properly in the first place.


Manually Select Suspend

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'

If you manually select suspend you can check that the screen switches off and that the power LED is flashing. Any fan that may be spinning should also switch off.

In my case, the screen would switch off but the power LED stayed on and the fan would continue to run if already doing so. The machine did not respond to any keypresses or mouse movements or pressing the power button (which would normally ‘resume’).

The usual tricks of Ctrl + Alt + f1 or f2, f3 etc had no effect. The only thing that could be done was to force the machine to shutdown by holding down the power button.

In order to provide consistent language to describe the problem, I’m going to call this ‘seizing up and requiring a forced shutdown’.


Nvidia Graphics

I don’t have nVidia graphics on my machine, but for some people experiencing suspend issues who do, there is a fix that has reportedly resolved the issue for a number of people.

It’s outlined here by cascagrossa:

https://askubuntu.com/questions/1029...041395#1041395

and basically involves adding the kernel parameter ‘nouveau.modeset=0’ in /etc/default/grub

The assumption is that you are using the open source ‘nouveau’ graphics driver (if you are experiencing suspend problems whilst using the proprietary nVidia graphics drivers then it’s worth trying nouveau instead just to be sure the fault isn’t with the proprietary drivers)

For those who are unfamiliar with Linux, you want to open up a terminal and use

sudo nano etc/default/grub

to change the line

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

to be

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nouveau.modeset=0"

(press Ctrl + x to exit, press ‘y’ to agree to save the changes and press 'enter' to accept the filename)

and then run

sudo update-grub

and reboot the machine.


s2idle

There has also been a problem with the machine not going into ‘deep’ sleep, but instead going into an ‘s2idle’ mode instead.

It’s easy to check, just type

cat /sys/power/mem_sleep

and you should see the default suspend mode with [square brackets] around it.

For the ‘normal’ suspend mode that most users expect, cat /sys/power/mem_sleep should return something like:

s2idle [deep]

If you have [s2idle] in the square brackets then s2idle is currently the default suspend mode.

The fix for that has been helpfully described here by monty47:

https://askubuntu.com/questions/1029...036122#1036122


Try An Older Kernel

I was unaware of a rather handy program called UKUU until I stumbled across a solution helpfully outlined by matalak here:

https://askubuntu.com/questions/1029...038528#1038528

It involves installing the Ubuntu Kernel Update Utility by following the steps from omgubuntu.co.uk:

https://www.omgubuntu.co.uk/2017/02/...-kernel-ubuntu

and then choosing any kernel from the 4.14 branch.

I chose the most up-to-date 4.14 kernel, mainly to see if the problem only turned up in the 4.15 branch, which it appears at least for my machine, that it did.

Under ‘Advanced options for Ubuntu’ in the grub menu you can then choose which kernel to boot into.

Using this method I was able to see that using 18.04 with a kernel from the 4.14 branch allowed suspend to work again without issue.


Bug Report

I have opened a bug report about my particular suspend issue and a few others have been afflicted with the same problem. I’ve not opened a bug report before, but I assume that the developers are busy and need to focus their time and energy on specific issues.

I was concerned that because the bug was only able to be reproduced on specific hardware combinations that it might not get any attention. I attempted to point people from AskUbuntu towards the bug report if the nVidia nouveau modeset trick didn’t help and the s2idle fix wasn’t at the root of their suspend problems.

That being said, whenever anyone added their voice to the bug report, I tried to show some appreciation that they’d taken the time to report it and also to confirm that the behaviour was a consistent failure to suspend, with the screen going blank, the power LED staying on and leaving an unresponsive machine that required a forced reset.

Unfortunately, this may have had a detrimental effect on the bug report, filling it up with discussion rather than a developer being able to look through and quickly see what the issue was.

I’ve not been told off for not keeping it succinct, and initially I thought it was important to put as much detail into describing the issue as possible, but looking at the bug report it has occurred to me that there’s quite a lot to read through, which might not be helpful to the busy developers.

Fortunately, despite not affecting a large number of users, one of the Canonical developers, Kai-Heng Feng, contacted the kernel team who applied a patch and he then posted the patched 4.15 kernel to test.

It’s in post #35 of the bug report: https://bugs.launchpad.net/ubuntu/+s...50/comments/35

The patched kernel has resolved my suspend issue and will hopefully be added into the upstream code, but for now I just have to make sure I don’t update the kernel when any updates are available.


Suspend Issues In 18.04 In General

I’d like to attempt to move the discussion away from the bug report and into this thread, so that anyone experiencing a similar issue can check for other fixes, discuss their findings and, if the problem seems to be a kernel issue too, can report their problem succinctly to the developers.

‘Suspend Issues In 18.04 In General’ is too large a topic to be helpful in a bug report, but should be a good place in the forums to gather all the issues and then be able to report them individually.

It was only by searching for a solution to my own problem that I became aware of a number of separate issues that had similar looking behaviour, so hopefully a bit of further discussion of people’s suspend issues will bring to light any other issues and help narrow down where things might be going wrong.

[cmeerw]

BTW, how do I find out what patch was actually applied in the kernel posted by Kai-Heng Feng (as the download is only for the binaries)?

[perryhelionsemail]

Hi cmeerw, not sure if this gives you the answer or if it's still a bit cryptic, but a few of the developer correspondances showed up as an email thread in my inbox (probably because my address was on the bug report) and it said:

It is reported that commit a192aa923b66a (ACPI / LPSS: Consolidate runtime PM and system sleep handling) introduced a system suspend regression on some machines, but the only functional change made by it was to cause the PM quirks in the LPSS to also be used during system suspend and resume.

While that should always work for suspend-to-idle, it turns out to be problematic for S3 (suspend-to-RAM).

To address that issue restore the previous S3 suspend and resume behavior of the LPSS to avoid applying PM quirks then.


The commit a192aa923b66a seems to be in linux-pm/drivers/acpi/acpi_lpss.c which I assume is up somewhere on the kernel.org site if you need more information, but it would certainly appear that that's where the patch was applied.

The result of the original kernel bisection between 4.14 and 4.15 is up on the bug report but it said:

a192aa923b66a435aae56983c4912ee150bc9b32 is the first bad commit
ACPI / LPSS: Consolidate runtime PM and system sleep handling

Kindest regards,
pHeLiOn

[ariake]

By the way, the Ubuntu 18.04 based Linux distributions are, of course, also affected by this 'bug'. The all new Linux Mint 19, is experiencing the same problem.
It also seems that the patched kernel done by Kai-Heng Feng is a revoked version because of some serious issues.

What's the plan to fix the bug? Will the fix made by Kai-Heng Feng will be merged to a newer version?

[perryhelionsemail]

Hi ariake, as far as I can tell from the bug report (Bug #1774950) the fix has been committed to the Cosmic Cuttlefish branch.

Cosmic Cuttlefish (Ubuntu 18.10) looks likely to be using a 4.18 or greater kernel, so the patch that currently fixes the suspend problem on our affected machines will be implemented in whichever kernel 18.10 will be using.

I would like to think that the fix will be backported to the 4.15 kernel, but I'm not entirely sure how it works - because 18.04 is a Long Term Support release they will probably stick with a 4.15 kernel until a later point release. I don't know if they will add the fix to the 4.15 kernel in an update or whether we will have to wait until they move the LTS to a later kernel.

In the bug report, Jacob Pedersen said that when the latest kernel update came through in the repos (kernel 4.15.0-29) that suspend started working for him again on his machine. I was pleased to hear this news but my problematic HP Pavilion (with an Intel 'Pentium' N3540) still seized up and required a hard reset.

For just now, I'm just keeping the patched 4.15 kernel that Kai-Heng Feng put together and avoiding any kernel updates. When I get a bit more time I might experiment with some of the more recent kernels using the Ubuntu Kernel Update Utility (details in the 'Try An Older Kernel' section in my first post but the UKUU details are from here). Some of the more recent kernels might have the patch applied already - I haven't tried any of them recently but they are up to 4.17.12 so far, so might be worth a look if you are curious.

I'm glad we've managed to get the bug looked into - the issue seems to be affecting quite a small number of specific machines - but I suspect we will have to either wait it out on the patched kernel or experiment with UKUU to find a more recent 'suspend friendly' kernel for the affected machines for now.

Kindest regards,
pHeLiOn

[perryhelionsemail]

@yeboster - this is just a quick note after seeing your post on the bug report. It seems likely that the bug outlined in Bug #1774950 is mainly affecting Bay Trail Atom Celeron/Pentium Cpu's.

There are other suspend issues with 18.04 however, so it would be best to see if it might be an s2idle problem or the nVidia drivers that are causing suspend to fail first. Take a look at the first post in this thread and see if any of the solutions that worked for others help fix your suspend problems.

If the suspend issue is with the nVidia proprietary drivers then the only people who can help there are the nVidia developers because the closed-source graphics driver model means that noone else is able to check the code, make modifications or fix any issues.

The nouveau graphics driver (the open source nVidia graphics driver) unfortunately seems to have had a bug in the driver code which has caused suspend to 'misbehave' on 18.04. I don't know if a fix has been issued for it yet, but if you are experiencing suspend problems with 18.04 it's definitely worth checking whether the nouveau.modeset=0 trick fixes it, because in that case you know it's a problem with the nVidia graphics rather than needing a patched kernel.

Let us know how you get on - it's not absolutely definite that only Bay Trail Atom Celeron/Pentium CPU's are affected, but it seems quite likely from the evidence so far - it would be useful to know what machine you are using, if trying to enter suspend causes the same 'seizing up and requiring a forced shutdown' behaviour and whether the nVidia nouveau or s2idle 'fixes' resolve your suspend issues.

[perryhelionsemail]

@smustgrave and @ariake,

If you have come here from the message in the bug report then it'd be really helpful to let us know here how you get on with checking whether the XPS has the same issue as those with a Bay Trail Atom Celeron/Pentium.

As mentioned, whilst searching on AskUbuntu and trying to find out what was wrong with my machine, I saw some issues with nVidia graphics and s2idle problems that exhibited the same behaviour as my machine but were not the cause of my suspend problems - my machine has only Intel Graphics and cat /sys/power/mem_sleep showed that it was trying to enter [deep] sleep by default rather than s2idle (I still followed the solution just in case, but to no avail) - the first post in this thread points at some of the AskUbuntu questions and solutions that helped fix it for others.

The s2idle problem was from an AskUbuntu question about a Dell XPS and I think most of the recent XPS laptops have nVidia graphics as well. There's a reasonable likelihood that those issues are giving you suspend problems and that you don't require a patched kernel to get suspend to work on your machines.

[yeboster]

Thank you for your reply!
I have an HP pavilion 15 (Intel i7- 6700HQ) with installed last 390 non free nvidia driver.
Sometimes the machine goes to suspend well, sometimes when I boot it up again, the gnome restarts and the session is recreated twice (I need to log in twice).
I've putted into the grub the nomode_set and I saw an improvement: before it was not working and now sometimes it works. The mem_sleep is [deep]
So I'm not sure what is the cause but I think I need to try the free driver.
I have a question: When I install the free driver, do I need to remove the modeset line? Basically what that line does? It blacklist the nouveau driver?
Also, why the free driver is the nouveau?
Sorry for too many questions but I've never covered this stuff in my new experience with Linux.

[perryhelionsemail]

@yeboster - hello, firstly it would be best for me to point out that I have not really had any experience using nVidia graphics. Whilst investigating what was going wrong with my machine when I tried to suspend, I searched on the AskUbuntu questions and saw several mentions of the nouveau.modeset=0 trick that helped out people with nVidia graphics experiencing problems.

The feedback from other users was that it solved a couple of problems on 18.04. There was even someone who couldn't get the live USB to boot but was able to by adding nouveau.modeset=0 to grub. Initially I thought it was just changing a setting on the nouveau driver, but as far as I can tell it is just disabling the nouveau driver on boot and stopping it from interfering with the proprietary drivers.

There is a way to remove the proprietary drivers and (assuming you also remove nouveau.modeset=0 from /etc/default/grub) it will fall back to using the nouveau drivers, but it might not be necessary to do that in order to get suspend to function correctly on your machine.

I'd recommend taking a look at this AskUbuntu question about nVidia graphics drivers: https://askubuntu.com/questions/6139...nvidia-drivers

As far as I can tell, if you add the ppa using:

sudo add-apt-repository ppa:graphics-drivers/ppa

and update your system with sudo apt update and sudo apt upgrade then it will update your proprietary nVidia graphics drivers to the latest versions. With a bit of luck, any suspend issues will have been fixed by now in the most up-to-date versions of the drivers.

The 'nouveau.modeset=0' parameter is probably still required to ensure that the nouveau drivers don't interfere, but hopefully you should be able to suspend and resume without further issues.

It would be interesting to know how you get on - the particular suspend issue I'm experiencing on my machine (without the patched kernel) looks very similar to people with s2idle and nVidia driver problems, so if anyone else joins the bug report about suspend issues it'll be good to know what has worked (or not worked) for nVidia users experiencing a similar looking problem.

[perryhelionsemail]

Kernel 4.17.14

Using 'Ubuntu Kernel Update Utility' (an easy way to try out other kernels) I have tried the most recent 4.17.14 kernel and suspend and hibernate both work fine on Kubuntu 18.04 so far.

I haven't tried 4.18 yet - it's available but might be a bit too 'bleeding edge' at the moment - I assume that the same patch that fixes the suspend issues is already in 4.18.

I'll keep running my machine with 4.17.14 and look out for any further odd behaviour, but it'll be nice not to keep having to make sure I don't accidentally update the 4.15 kernel and break suspend again