Suspend fails in Ubuntu and Kubuntu 18.04 but works fine in Ubuntu and Kubuntu 17.10 (and on Kubuntu 18.04 using kernel 4.14.47)

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1774950/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1774950

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.17 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.17

Hi Joseph - I have used UKUU to try the 4.17 kernel. As far as I am aware, this is an easy way to try the 4.17 kernel ubuntu build.

Can you just confirm that I'm correct in that assumption or do i need to try a different method? (i.e follow the wiki.ubuntu.com/KernelMainlineBuilds method rather than using UKUU?)

UKUU 4.17 latest version exhibited same suspend problem last time. I will try it again though and let you know.

Assuming using UKUU to try various kernels is fine, I have tried the following kernels and experienced the same suspend failure:

4.17.0
(4.17.0-041700.201806032231)

4.16.13
(4.16.13-041613.201805300810)

4.15.18
(4.15.18-041518.201804190330)

4.15.1
4.15.1-041501.201802031831

Using the latest 4.14 kernel (4.14.47-041447.201805301730) allows suspend to work as expected.

The kern.log shows that for a failed suspend on the 4.15, 4.16 and 4.17 kernels it only gets as far as

PM: suspend entry (deep)

and there are no further entries until startup (after having to shut the machine down)

A succesful suspend using the 4.14 kernel gives the kern.log entries as

Jun 4 23:27:28 PAviX360 kernel: [ 50.875164] PM: suspend entry (deep)
Jun 4 23:27:28 PAviX360 kernel: [ 50.875167] PM: Syncing filesystems ... done.
Jun 4 23:27:33 PAviX360 kernel: [ 50.883987] Freezing user space processes ... (elapsed 0.
001 seconds) done.
Jun 4 23:27:33 PAviX360 kernel: [ 50.885799] OOM killer disabled.
Jun 4 23:27:33 PAviX360 kernel: [ 50.885800] Freezing remaining freezable tasks ... (elaps
ed 0.001 seconds) done.

etc...

So when it fails at 'PM: suspend entry (deep)' using 4.15 kernels and later, it does not move on to PM: Syncing filesystems etc.

kernel-bug-exists-upstream tag has been added and changed tag to say 'bionic' instead of 'artful' as bug does not affect machine in artful Ubuntu or Kubuntu 17.10

Have now tried using 4.14 kernel with Ubuntu 18.04 and it fixes the problem. Using a 4.14 kernel with Ubuntu 18.04 and Kubuntu 18.04 allows suspend to work as it should.

In the case of Ubuntu 18.04, it is the same for Ubuntu on X or Wayland. i.e both fail on a 4.15+ kernel and both work using kernel 4.14.47

(Have tried Ubuntu 18.04 with the latest 4.17 kernel from UKUU as well and it still fails to suspend, so feel sure that kernel-bug-exists-upstream )

Note - the 4.17 kernel i have tested Ubuntu 18.04 with is 4.17.0-041700.201806041953

I'm affected by this bug, too.
System is Acer E13 Laptop with 250G SSD, Intel Celeron N2940, 4GB RAM
Initial and only install on this system was Ubuntu 16.04(where I had to insert a parameter into GRUB to prevent another system freeze bug to occur), uprgaded flawlessly to 17.10 and then to 18.04. And since the upgrade to 18.04, this bug, as extensively described above, with the same symptoms, was present.
I fiddled a around a lot, with some hints directing me to either the fishy power management of the cpu (the above-mentioned, different bug, ostensibly originated from there) or the still-faulty new graphics driver, albeit I don't really know if that nouveau Graphics driver is even compatible with my Intel cpu graphics.
What finally solved the bug for me was the above-recommended downgrade (via ukuu) to kernel 4.14 - so no I'm running 18.04 with Kernel 4.41.41 with this bug no longer occuring

What's left to do now, I believe, is to klick away the kernel upgrade notifications and hoping for a fix in a newer kernel :)

@Matze thanks for adding to the bug report - Here's where it starts to get interesting :)

My problem laptop is an HP Pavilion x360 11-n013na with a quadcore Intel Pentium N3540
4GB of DDR3 Ram
250GB SSD (Samsung 850 EVO)

I also have an HP Stream 11 with an Intel Celeron N2840 that does NOT have any suspend problems.

The HP Stream is almost identical hardware-wise. Components such as the entire screen assembly, battery and USB board are inter-changeable (which I know because I have actually swapped them over!)
So for the Stream to be fine, but the Pavilion to have suspend problems makes me curious about the differences.

The Stream that suspends has eMMc storage and 2GB Ram (soldered to the main board :( )

With your Acer E13, you have an Intel Celeron based Atom CPU (N2940) coupled with an SSD.

My Pavilion also has an Intel Celeron based Atom CPU (N3540) coupled with an SSD.

(The 'Pentium' title for the N3540 is just a branding thing I believe - same architecture)

So it is pure conjecture at the moment, but if we gather more people experiencing the same problem, I wonder if there might be a significant number of these Atom-style Celeron variant CPU's with an SSD as their main storage experiencing problems with suspend.

Matalak's Acer Aspire ES1-511 (from https://askubuntu.com/questions/1029405/ubuntu-18-04-crashes-on-resuming-from-suspend where I found the 4.14 kernel solution) is also an Intel Celeron (N2830) CPU as far as I can tell from the specs.

I've asked him to contribute to the bug report, but don't think he's seen my requests yet. I'll ask if he's using an SSD as well.

(collisionTwo from the same forum question above says he was experiencing this issue with an XPS 9560, mind you, which is a Kaby Lake Mobile CPU, so it's still a bit of conjecture until we get more specs from others experiencing the 'doesn't actually suspend and needs a hard reset to do anything' probem.)

This requires kernel bisection between v4.14 and v4.15.

$ sudo apt build-dep linux
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd linux
$ git bisect start
$ git bisect good v4.14
$ git bisect bad v4.15
$ make localmodconfig
$ make -j`nproc` deb-pkg
Install the newly built kernel.
If the issue still happens,
$ git bisect bad
Otherwise,
$ git bisect good
Repeat to "make -j`nproc` deb-pkg" until you find the commit that causes the regression.

sudo apt build-dep linux gives me the following error:

Reading package lists... Done
E: You must put some 'source' URIs in your sources.list

Kai-Heng Feng - can i just check if you're asking me to do the kernel bisection or is that instructions for someone who knows what they're doing?

This bug also affects the Dell XPS 13 9370.

@Mark Stosberg - thank you for adding your voice to the bug report. I was wondering if this particular bug was mainly to do with Bay Trail (Celeron/Atom) based CPU's using an SSD as their main storage, but if it is affecting the Dell XPS 9370 then that rather scuppers my theory ;)

Can you just confirm that you've tried to get suspend working using the nouveau.modeset=0 trick (you have nVidia graphics?) and also checking whether it's an s2idle problem? There are a list of steps with details here: https://askubuntu.com/questions/1029474/ubuntu-18-04-dell-xps13-9370-no-longer-suspends-on-lid-close/1044270#1044270

I've been assuming that some XPS 9370's have resolved their suspend issues with other fixes because the answer by monty47 was accepted.

If you could confirm that none of the other solutions gave good results and only by using a 4.14 kernel on 18.04 solved the suspend issue, then that would really help. And also force me to rethink my theory :)

Please include your hardware - CPU, RAM and storage device (It's an SSD right?).

Kindest regards.

@pHeLiOn - I think you are the only one who can do the kernel bisection - you have the hardware that doesn't work. It's not hard just follow Kai-Heng Feng's commands. You got the message "E: You must put some 'source' URIs in your sources.list" because you didn't enable source packages in your sources list. You can do this in Software & Updates application, first tab.
You can find how to do bisection here: https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git
It is really easy.

@jail-j - Thank you for your comment (was in the middle of writing a post to ask about it on linuxquestions.org :) ). That link will help out a lot!

I'm having the exact same problem in a clean installation of Ubuntu 18.04.
I'm on a Lenovo Legion Y720. Even suspending by command or by closing the lid, it hangs. I can see a dash blinking in top left of the screen. In that stage, the laptop is not completely dead: the numlock button stills toggles the numlock led. But when I hit ctrl-alt-F1, then the blinking dash disappears and numlock button doesn't even work any more. From then, I have to hard reset the machine. My logs look just like the OP described, so the machine actually thinks it went to sleep.
It's odd that it doesn't happen all the time. Sometimes it suspends correctly.
I'm using nVidia drivers. Some said that driver might be the problem, although some people report having the same problem with intel cards.
Not sure if related, but I got LOTS of these on dmesg:

[dom jun 10 20:55:04 2018] pcieport 0000:00:1c.4: PCIe Bus Error: severity=Corrected, type=Data Link Layer, id=00e4(Transmitter ID)
[dom jun 10 20:55:04 2018] pcieport 0000:00:1c.4: device [8086:a114] error status/mask=00001000/00002000
[dom jun 10 20:55:04 2018] pcieport 0000:00:1c.4: [12] Replay Timer Timeout

Also, in those cases where it actually suspends ok, sometimes it randomly wakes up as if someone would have opened the lid (many times I double checked it was actually suspended before putting the laptop in my backpack and then found it freakingly hot because it turned on by itself).

I'm running Ubuntu on Samsung SSD 850 Pro and I also have a WD Black M.2 on the pci express slot with a different SO.

Thanks @kaihengfeng for the bisection instructions and @jail-j for pointing me in the right direction. (It's probably worth mentioning that sudo make -j`nproc` deb-pkg was needed for the build to work)

Here's the most recent result:

git bisect bad
a192aa923b66a435aae56983c4912ee150bc9b32 is the first bad commit
commit a192aa923b66a435aae56983c4912ee150bc9b32
Author: Rafael J. Wysocki <email address hidden>
Date: Mon Oct 16 03:29:55 2017 +0200

    ACPI / LPSS: Consolidate runtime PM and system sleep handling

    Move the LPSS-specific code from acpi_lpss_runtime_suspend()
    and acpi_lpss_runtime_resume() into separate functions,
    acpi_lpss_suspend() and acpi_lpss_resume(), respectively, and
    make acpi_lpss_suspend_late() and acpi_lpss_resume_early() use
    them too in order to unify the runtime PM and system sleep
    handling in the LPSS driver.

    Signed-off-by: Rafael J. Wysocki <email address hidden>
    Acked-by: Greg Kroah-Hartman <email address hidden>
    Reviewed-by: Ulf Hansson <email address hidden>

:040000 040000 b4ef369c698a10cec8d6224fdc3b8f287eb853b1 20327192ca09ecc0cf0b24b62fdb915ea303b988 M drivers

wasn't sure if I'm meant to keep going so I've run sudo make -j`nproc` deb-pkg again to see what it comes up with.

@pHeLiOn -- Matalak has joined! Sorry for the delayed response. Thanks for putting this bug report together! Here's the linked answer, as requested: https://askubuntu.com/questions/1029405/ubuntu-18-04-crashes-on-resuming-from-suspend/1043397#1043397 .

I am seeing this problem on an Acer Travelmate B115 (Intel Pentium N3540 CPU, 4 GB RAM, no SSD)

@ferconsigli - thanks for reporting your issue too. Much appreciated!

From the specs for a Lenovo Legion Y720 they seem to be using 7th Generation Intel Core processors - is that what's running on your Lenovo Legion with the suspend problem?

In an answer to matalak's question, cascagrossa said:

  I believe it is the buggy nouveau driver. Try adding:

  nouveau.modeset=0

  to GRUB_CMDLINE_LINUX in the /etc/default/grub file, after that run:

  sudo update-grub
  sudo reboot

One of the comments said that it worked for them and others.

I don't think that it will fix it for you but I'm curious to know if it means your laptop will still fail to suspend but in a different way ;)

@perryhelionsemail, well, now that you suggested that, I realize that as I'm using the privative nvidia-driver-390, if the problem is actually related to that, there's nothing the open source community could do.
I will switch to the nouveau driver and see if the problem persists (and if it does, will try the modeset tweak).

As for the other question, yes, the laptop has a 7th gen i7-7700HQ.

@qwertzy - Hi Matalak! Glad to see you found my many messages :)

I'd tried a few suggestions from AskUbuntu, but it didn't seem like many people were experiencing the same problem and was just going to go back to 17.10 and hope an update fixed it. Fortunately I found your UKUU solution, so thanks for taking the time to write it up in the forums and adding to the bug report too!

I'm still finding it a puzzle why it affects some machines and not others.

Recently tested a machine with a Live USB of 18.04 that has an N2830 (and no SSD) and it has definitely got the same suspend problem, but experienced no issues with a machine using an N2840 (?).

So my 'Bay Trail Atom with an SSD' adhoc theory is unravelling somewhat :)

Just in case you see anyone else on the forums with suspend issues, could you point them towards my '6 Steps To Less Sleepnessness' answer: https://askubuntu.com/questions/1029474/ubuntu-18-04-dell-xps13-9370-no-longer-suspends-on-lid-close/1044270#1044270 if you don't mind.

(it might have a little bit too much detail, but it's basically - Is there an nVidia graphics issue? Does 'suspend' work at all? What happens with a Live USB? Is it an s2idle problem? Does the 4.14 kernel fix it? Can you add to the bug report? )

@cmeerw - thanks for letting us know you're experiencing this issue too!

I was hoping there might be a more obvious pattern, but it's good to see that an N3540 *without* an SSD is still affected by the suspend issues. Looks like the SSD might not be part of the problem.

Can I just check - have you been able to try 18.04 with a 4.14 kernel and find that it lets you enter sleep properly and resumes as normal?

Using the latest 4.14 kernel is just a temporary fix, so hopefully the kernel bisection result points towards a specific area that can be looked into.

@ferconsigli - thanks, that'd be great if you could check!

I don't have nVidia graphics on any of my machines so I'm not familiar with any issues except from people saying that it worked for them on the forums.

There was a question where M. Plyer couldn't get a Live USB to work and the 'nomodeset' trick worked: https://askubuntu.com/questions/1043842/running-ubuntu-via-live-usb-error-on-dell-xps-15-9560 and in Matalaks question where I found his solution, an answer that worked for a couple of people was the 'nouveau.modeset=0' fix.

I'm probably over-suspicious of any problem somewhow being related to nVidia but it might be interesting to see if there's any difference in behaviour :)

Here are a few thoughts:

I've tested other Debian-based distributions whose display managers are Gnome or XFCE, running the 4.15 kernel, and the same problem persists. Perhaps we should look wider than just solutions for Ubuntu. For example, Fedora seems to have the same problem, as does Arch Linux ( https://bugs.archlinux.org/task/57511 and https://bugzilla.redhat.com/show_bug.cgi?id=1551262 , respectively). I just notice that almost all links above are directly related to Ubuntu, and that could be limiting.

Has anyone looked into the solutions for Spectre and Meltdown? Perhaps the latest solutions have caused problems with the Intel hardware.

@perryhelionsemail suspend works fine with the kernel from 17.10, but not with the kernel from 18.04 (everything else is the same, just selected the old kernel in grub).

@Matalak - took a look at your redhat bugzilla link and the behaviour that todd describes is an exact match! Curiously enough, todd seems to be using a standard PC setup rather than a laptop.

At the end of the redhat bugzilla post Laura Abbott suggests that todd files a bug report with the upstream maintainers at bugzilla.kernel.org and when I searched for suspend bugs I found: https://bugzilla.kernel.org/show_bug.cgi?id=199025 (last entry was 10th May)

A few thoughts:

- kernel bug 199025 'Suspend hangs. Never fully suspends and impossible to return to running state.' has been filed against this issue. The 'Status: NEEDINFO' and the last comment on it being from the 10th of May is not particularly encouraging :(

- I'm not entirely sure how all of this works (this is the first bug report that I've filed) but my initial thoughts were to get anyone with suspend issues to add to the bug report and list their hardware, so that there might be a clearer picture of how many people this was affecting and what machines seem to be affected.

- I assumed that nobody would pay any attention to this seemingly 'edge-case hardware combination issue' until it was ascertained that it affected a good many more people.

- I'm pleased to see that I was incorrect in my assumption and that as far as I can tell from an email (think I got added to a list for starting the bug) a canonical team member, Kai-Heng Feng, has been in touch with a kernel.org developer about the kernel bisection report, who has made a patch to test.

So I think what happens is that users report bugs to their specific distro (i.e Ubuntu, Fedora, Debian) and the distro developers/maintainers can then narrow it down and report the problem to the maintainers of the affected part of the project.

In this case, what seems to be a kernel-related problem is reported to the kernel maintainers by the Ubuntu developers.

Since it only seems to be affecting a few specific hardware combinations, it means any fixes will have to be tried out by someone with the 'problem hardware', who can then report back whether the issue is fixed.

(I don't mind testing things out but don't really know what I'm doing, so if there is a patch to try I wouldn't know how to apply it.)

I'm very tempted to let the bugzilla.kernel.org folks know that bug #199025 is affecting us too, but the Ubuntu maintainers might be in touch with them already.

Ah flip! writing "kernel bug 199025" automatically links it to an *Ubuntu* bug with the same number from 2008!

The bug with that particular number is this: https://bugzilla.kernel.org/show_bug.cgi?id=199025

@cmeerw - that's great, thanks for confirming that! (I think I made a clean install of 18.04 but hadn't even thought of being able to use the old kernel if you've upgraded :) )

Here's a more succinct update of how things seem to be progressing:

- There's a bugzilla.kernel.org bug report that describes this same behaviour: https://bugzilla.kernel.org/show_bug.cgi?id=199025

- A kernel bisection between v4.14 and v4.15 gives this result:
git bisect bad
a192aa923b66a435aae56983c4912ee150bc9b32 is the first bad commit
commit a192aa923b66a435aae56983c4912ee150bc9b32
Author: Rafael J. Wysocki <email address hidden>
Date: Mon Oct 16 03:29:55 2017 +0200

    ACPI / LPSS: Consolidate runtime PM and system sleep handling

    Move the LPSS-specific code from acpi_lpss_runtime_suspend()
    and acpi_lpss_runtime_resume() into separate functions,
    acpi_lpss_suspend() and acpi_lpss_resume(), respectively, and
    make acpi_lpss_suspend_late() and acpi_lpss_resume_early() use
    them too in order to unify the runtime PM and system sleep
    handling in the LPSS driver.

    Signed-off-by: Rafael J. Wysocki <email address hidden>
    Acked-by: Greg Kroah-Hartman <email address hidden>
    Reviewed-by: Ulf Hansson <email address hidden>

:040000 040000 b4ef369c698a10cec8d6224fdc3b8f287eb853b1 20327192ca09ecc0cf0b24b62fdb915ea303b988 M drivers

- from an email list I saw that @kaihengfeng has contacted a kernel.org developer who has written a patch to test.

- I don't know if I'm supposed to test this patch (i might just be added to the email list because I opened this bug report) or whether Kai-Heng Feng will post here to let others try a kernel with the patch applied and see if it works.

pHeLiOn, please try the kernel here. It includes the patch from Rafael.
https://people.canonical.com/~khfeng/lp1774950/

@pHeLiOn: Thanks for putting in the effort! Seeing that this is not resolved yet, I figured that though I'm not a kernel-hacker/sysadmin-guru by a long shot, I'll throw my tidbits in, in the faint hope that someone gets onto the right track.
(For rememberance: Acer Aspire E13, Intel Celeron N2940, 4GB RAM, changed standard HD for a 250G SSD)

1.)
The 'other' bug I mentioned above was (I believe) resolved by adding the statement intel_idle.max_cstate=1 in the grub configuration file. However, my first inquiries into the problem (System freezes, not resolvable by anything (didnt try remote access, though)) pointed me to a potential problem with the SSD HD. Now, I cannot, for the life of me, remember what it was, exactly, but it was something along the lines of Point No. 6 on this site:
http://bernaerts.dyndns.org/linux/74-ubuntu/250-ubuntu-tweaks-ssd
I remembered this because you narrowed it down to some CPU types PLUS SSD, so, maybe there's a hint somewhere.

2.)
In my above Post, I mentioned that my problem was 'fixed' in 18.04 by downgrading the kernel, as mentioned.
Well, it IS fixed in a way, but there remain some oddities - for example: After Boot, the cooling fan is on (running at a moderate pace at first) no matter what, even after a cold boot. It takes putting the system into suspend and out again (which, as mentioned, works now!) so that the fan is turned off completely - and, somewhat worringly, stays off. I've not tested running the system at full power to see if the cooling fan comes on again, when required - so as of now, I take it a bit on 'good faith' that it will :)

These are my further observations - hope it helps somehow!

@redroach - Thanks Matze for adding some more details - it's good to have as much information on how people are affected and on what hardware because this is an odd bug that isn't easy to reproduce, except seemingly with a few specific hardware combinations.

- My initial thought that it seems to be a 'Bay Trail Atom coupled with an SSD' problem has not held up. @cmeerw had a machine with the same N3540 processor as mine without an SSD and it had the same problem. I also managed to try a machine with an N2830 processor without an SSD and it had the same problem too using a Live USB. So why it works fine on a machine with an N2840 processor is peculiar.

- It might be worth trying the 4.14 kernel again without the intel_idle.max_cstate=1 in the grub configuration file, just to check whether the other odd behaviours might be due to that. Changing the cstate value will likely affect your battery life so it's not an ideal fix.

- There is a patch that has been written (by kernel.org developer Rafael) and Hai-Keng Feng has posted a kernel with the patch applied. Details in the next post... :)

@kaihengfeng the patched kernel works for me on an Acer Travelmate B115 with Intel Pentium N3540 CPU.

@kaihengfeng - thanks for the patched kernel link. I have installed it and tested it on my machine and suspend now works as it should! I will continue running it over the next couple of days and check for any odd behaviour but it certainly seems to have fixed the 'suspend' problem. Many thanks!

Anyone else experiencing this bug might also want to test out the kernel that @kaihengfeng has kindly put together with the patch from Rafael. It's in his post (#35) but here's the link:
https://people.canonical.com/~khfeng/lp1774950/

It'll be interesting to check that it fixes suspend issues for other folks too. The only thing I've noticed so far is that it makes a weird click sound through the speakers as it goes into suspend (probably when it switches them off) but that is a small price to pay for a working suspend function!

- I downloaded all the files, put them in a folder called KernelFix and then opened up a terminal. I changed directory ( cd /Downloads/KernelFix ) and then used sudo dpkg -i to install them.

- I'm fairly incompetent so tried sudo dpkg -i linux-image-unsigned-4.15.0-24-generic_4.15.0-24.26~lp1774950_amd64.deb first which told me I needed to install the modules.

- I installed both module .debs using sudo dpkg -i and then installed the kernel again just to be sure.

Anyway, that seems to have worked for me and I'm now running Kubuntu 18.04 with a 4.15 kernel and suspend works fine!

@kaihengfeng update: suspend seems to work with the patched kernel, but not hibernate.

@perryhelionsemail did you test hibernate as well and does it work for you?

@cmeerw - ah, I never use hibernate normally. I'll give it a try and get back to you.

@cmeerw - It took me a while to realise that getting hibernate to work on 18.04 required adding the kernel parameter 'resume=UUID=uuidofswappartition' (and also 'resume_offset=' if you're using a swap file) to /etc/default/grub.

(Ubuntu 16.04 and Kubuntu 16.04 will hibernate happily without the 'resume=' parameter added, so I was starting to wonder if hibernate was working on any machine after 16.04!)

Tested using `sudo systemctl hibernate` on the HP Pavilion N3540 with suspend issues. The results are the same for both Ubuntu and Kubuntu 18.04.

kernel 4.14.47

- Hibernate function works as it should

kernel 4.15.0-24 (with patch applied)

- Hibernate begins as normal but system does not shut down by itself. PowerLED stays on. Machine unresponsive. Holding down the power button to force shutdown is required.

- Upon reboot, the system resumes from where it left off, as if hibernate had worked fine.

--kern.log entries look the same irrespective of whether the system hangs and requires forced shutdown.

 PM: hibernation entry
 PM: Syncing filesystems ...
- (timestamp gap of about a minute before next entries - shutdown then reboot) -
 PM: done.
 Freezing user space processes ... (elapsed 0.001 seconds) done.
 OOM killer disabled.
 PM: Marking nosave pages: [mem 0x00000000-0x00000fff]
etc...

So hibernate almost works as it should but requires a forced shutdown in the 4.15.0-24 kernel with the patch applied.

(Also tested a machine that doesn't experience suspend issues and hibernate works as it should with standard up-to-date Ubuntu 18.04 with kernel 4.15.0-23)

@kaihengfeng - thanks for helping with this bug, very much appreciated. The 4.15.0-24 kernel with the patch applied solves the 'suspend causing system to seize up' problem.

When trying to use hibernate on the 4.15.0-24 kernel with the patch applied, the system experiences a similar 'seize up' requiring a forced shutdown. Upon shutdown and restart, hibernate restores the previous state as if it never encountered any problem.

Please advise the best way to proceed.

The 'seizing up and requiring forced shutdown' is similar to the suspend bug and may be very closely related. Is this a good time to point it out to the patch writer?

Or is the correct procedure to wait for the fix to the suspend bug to be applied, and then open a new bug report about hibernate?

@perryhelionsemail: Thank you for putting all this info together and for staying at it! :)

Just to weigh in: I am affected, too, on an ACER Aspire V 11 Touch (V3-111P-P06A), N3530 CPU, Intel onboard graphics, 8GB RAM (not original) and 480 GB SSD (not original), and having the boot flag intel_idle.max_cstate=1 activated.

I just installed the kernel patch provided by @kaihengfeng. It seems to fix the suspend/resume issue for me, as well. Haven't tried hibernate, yet.

However, two new issues became apparent for me right away:

1. Upon system start, after the Ubuntu loading screen (the purple-ish screen with the five dots below "Ubuntu"), the screen goes black with a blinking cursor on the top left, and later black altogether, and stays that way for quite some time, sometimes for minutes, until I finally get to the greeter and can login to my DE (Cinnamon 3.8). This does not happen with 4.15.0-23, pre-patch. While "waiting", I can log in to the TTYs, however.

2. I am also seeing a lot of graphics issues now, parts of the background and panel wildly flickering black; looks like some problem with transparencies of panels, desklets and notification popups. Just to be sure, I just checked back by booting back and forth between pre-patch kernel and patched kernel. In 4.15.0-23 I couldn't observe any such flickering thus far.

As I just upgraded to 18.04 this last weekend, and instantly ran into another problem (default Ubuntu and Cinnamon counter-acting each other) which I managed to solve only recently, I don't really have much mileage with 18.04 so far. So, possibly, the above "new" issues are totally unrelated to the patch. But still, apparently, the issues don't occur without the patch.

I am a Linux Mint user, of course which is downstream from Ubuntu. At the bottom of my post is an "inxi -Fxz" output with my machine info. I am replying because I am getting issues with exactly the same kernels (4.15 and up), and 4.14 installed unconventionally via Ukuu seems okay.

My problems that I noticed were:

1) plugged-in HDD (Dell Latitude media bay, SATA bus), no drive recognized. Reboot with drive plugged in required.

2) wireless settings in Dell BIOS go ignored:
   a) wireless switch (WLAN, WWAN, Bluetooth) -this is three checkboxes to configure each to be controlled by the physical switch on the right side of laptop.
   b) wireless enable (WLAN, WWAN, Bluetooth) -again, three checkboxes, these enable or disable each.

The resulting behaviors for 2) included physical wireless switch on right-hand side of laptop being enabled, even though I had it disabled in BIOS. Also wireless connectivity had dropouts.

The wireless devices I had disabled in the BIOS settings also remained up and running. This meant that the Bluetooth couldn't effectively be disabled at BIOS settings.

Different from everyone else's results. These are just the things I noticed. I have verified this to be related to kernels 4.15 - 4.17.1 (using UKUU), which is why I am replying here.

Below are my "inxi -Fxy" results:

~ $ inxi -Fxz
System: Host: travel Kernel: 4.14.50-041450-generic x86_64 (64 bit gcc: 7.3.0)
           Desktop: Cinnamon 3.6.7 (Gtk 3.18.9-1ubuntu3.3)
           Distro: Linux Mint 18.3 Sylvia
Machine: System: Dell (portable) product: Latitude E6420 v: 01
           Mobo: Dell model: 0X8R3Y Bios: Dell v: A24 date: 05/12/2017
CPU: Dual core Intel Core i7-2640M (-HT-MCP-) cache: 4096 KB
           flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) bmips: 11173
           clock speeds: max: 3500 MHz 1: 798 MHz 2: 967 MHz 3: 931 MHz
           4: 806 MHz
Graphics: Card: Intel 2nd Generation Core Processor Family Integrated Graphics Controller
           bus-ID: 00:02.0
           Display Server: X.Org 1.18.4 drivers: intel (unloaded: fbdev,vesa)
           Resolution: 1600x900@60.00hz
           GLX Renderer: Mesa DRI Intel Sandybridge Mobile
           GLX Version: 3.0 Mesa 17.2.8 Direct Rendering: Yes
Audio: Card Intel 6 Series/C200 Series Family High Definition Audio Controller
           driver: snd_hda_intel bus-ID: 00:1b.0
           Sound: ALSA v: k4.14.50-041450-generic
Network: Card: Intel Centrino Advanced-N 6205 [Taylor Peak]
           driver: iwlwifi bus-ID: 02:00.0
           IF: wlp2s0 state: up mac: <filter>
Drives: HDD Total Size: 128.0GB (53.4% used)
           ID-1: /dev/sda model: Samsung_SSD_850 size: 128.0GB
Partition: ID-1: / size: 115G used: 62G (57%) fs: ext4 dev: /dev/sda1
           ID-2: swap-1 size: 2.56GB used: 0.00GB (0%) fs: swap dev: /dev/sda2
RAID: No RAID devices: /proc/mdstat, md_mod kernel module present
Sensors: System Temperatures: cpu: 58.0C mobo: N/A
           Fan Speeds (in rpm): cpu: N/A
Info: Processes: 184 Uptime: 36 min Memory: 1175.6/7852.4MB
           Init: systemd runlevel: 5 Gcc sys: 5.4.0
           Client: Shell (bash 4.3.481) inxi: 2.2.35

@user-unknown - thanks for the information, it's good to hear that the patch is helping sort out the suspend issues. Interesting to see it's another Bay Trail Atom type CPU that seems to be affected too.

I haven't experienced any graphical issues so far. I'm mostly running Kubuntu but also have a separate install of Ubuntu with the standard Gnome desktop. Both have been running fine with the patched 4.15 kernel and suspend issues are not present anymore.

I'm curious about the graphical issues only being present with the patched kernel. I'd be tempted to think they are due to the different desktop environments somehow interefering with each other, but it's odd that they are not present with a different kernel.

Would it be possible to try it without the cstate flag? I'd be interested to know if there is any difference in behaviour.

@noreasternhumidty - I'm interested to see the information you provided but I don't think it will get looked into by posting on this bug report :)

I had a quick look for 'wireless' bugs that are open but only found this one that looked vaguely similar to what you described: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774102

This is my first bug report so I'm still finding my way around, but I think it works something like this:

- If you are experiencing any issues with your distribution, it's helpful to check on the forums (or something similar to AskUbuntu) to see if anyone else is experiencing the same issue. This helps rule out the possibility that it's just something specific to your machine.
https://forums.linuxmint.com/

- You can open a bug report stating the issue (e.g 'BIOS settings for Wireless and Bluetooth are ignored in kernels 4.15 and above')
https://bugs.launchpad.net/linuxmint

- In this case, because it's Linux Mint you'd be best to get in touch with their developers. If the issue affects something used by other projects (e.g the kernel) then I think they will be in the best position to check the details and offer suggestions first and then pass on the information to the relevant project.

This bug specifically is just about suspend not working on 18.04. It's only affecting a small number of machines but it's been great to see that it's being looked into. One of the Ubuntu developers passed along the information to a kernel.org developer, but only after getting more information and narrowing down the cause of the issue.

I think this is the normal procedure for bugs of this kind. Start with the Linux Mint forums and then open a bug report if you can't find a fix for it and then it should get looked into.

Thanks for confirming. My resonse was mainly due to the latest Linux Mint beta, which uses the 4.15 kernel as its base (there is no option to go lower). So this is something that they will have to eventually solve. I'll take a look there.

BTW The out-of-distro kernels installed by Ukuu broke my Apt system, I wasn't able to install or remove any software until I used Ukuu to remove the out-of-distro kernels. So that isn't an option anyhow.

@perryhelionsemail - I am really hesitant to removing the max_cstate boot flag: I had to set this in order to avoid random and total system freezes. And that bug seems to be anything but fixed: https://bugzilla.kernel.org/show_bug.cgi?id=109051

So, with due respect to curiosity – not gonna try that. ;)

However, it seems I found a solution for now for my flickering graphics issues.

I tried Gnome Shell (Ubuntu's default DE). There I did NOT encounter any flickering.

But Gnome Shell isn't a Desktop Environment I would want to settle on – I'll save you my random rant about it. :) And that was not my solution.

In trying to find a fix for my previously mentioned Cinnamon login-crash bug, I had upgraded Cinnamon to the latest stable version 3.8.3 via a PPA (the current version in Ubuntu's repo is 3.6.7). Today, I purged the PPA and downgraded Cinnamon to the older Ubuntu's repo version. As a result, the flickering issues with the patched kernel seem to be gone, so I'm mostly good for now, as far as I can see. :)

To summarize:

- The patched 4.15.0-24 kernel enables me to suspend-to-ram.
- The patched 4.15.0-24 kernel brings a new issue for me: A minute-long wait before I get to the Ubuntu greeter and am able to login to a DE. This does not happen in 4.15.0-23.
- The patched 4.15.0-24 in combination with latest Cinnamon 3.8.3 (via PPA) causes graphics flickering big time. This does not occur in 4.15.0-23, either.

So, while indeed restoring suspend, the patch still seems to be missing something.

@kaihengfeng - Is there any way I might help debugging or provide additional info?

Do you have swap file or swap partitions? Newer systemd is required for swapfile, see LP: #1760106.

Try "systemd/237-3ubuntu10.1" in bionic-proposed.

@kaihengfeng I have got a swap partition

@kaihengfeng - tested Hibernate function (with kernel 4.15 with patch applied) on Ubuntu 18.04 with a swap file and Kubuntu 18.04 with a swap partition on the same machine.

Both experienced same issue in the same way - hibernation starts, system freezes with screen off and powerLED on (instead of shutting down by itself), after forced shutdown hibernation resumes as if it all went fine.

Using the swap file or swap partition did not seem to affect the behaviour.

Both completed hibernation cycle without issue using kernel 4.14.

@userunknown - I'd try using 'less /var/log/kern.log' after you've logged in to see if there are any clues to why there's such a long wait before the login screen.

I haven't experienced any random and total system freezes with the two Bay Trail CPU machines I've been testing and using, but can understand if you have that you'd not be keen to try without the 'cstate' parameter.

As far as I can tell, there's not been much activity on the bug report that you linked to since April. The most recent posts are someone sending information about a non-Bay Trail processor (and it being discussed that it's a different bug that's affecting them), someone not getting the microcode update automatically in Manjaro and then a link or two to microcode updates.

I'd be tempted to think that if you have the latest microcode updates (if 'dmesg | grep micro' says you've got revision 836) then it could be worth trying without the 'cstate fix' to see if it's still needed. (preferably not testing it when doing important work! ;) )

I don't know if the graphical issues are somehow linked to the 'cstate' usage, but it'd be good to rule it out.

I've not had any graphical issues (using Ubuntu & KDE Plasma) or pre-login delays yet and assume @cmeerw would have mentioned it if it had occurred too.

Is anyone else experiencing graphic flickering issues or long delays before the login screen when using the 4.15 kernel with the patch applied?

I'm running an Thinkpad X1 carbon (so no nvidia anything running), but I am experiencing this same behavior. Also, it seems like this is the kind of thing that should go in to the release notes. It cripples laptop users and in my case has caused data loss.

@sams-james - what CPU does your Thinkpad X1 Carbon have? (Is it i5-6300U? There's a lot of different generations of them with different CPU's)

The problem is that only a few machines seem to be affected. From my own tiny sample size of 4 laptops that I've tried and tested, only 1 of them had this suspend issue on 18.04.

When I first encountered suspend causing the system to completely seize up, I thought it'd be all over the forums with people complaining, but for a large proportion of people it's working fine.

For some folks, suspend doesn't work thanks to a nVidia driver problem and there's a 'modeset' fix for that. There was also an s2idle problem for a few people, which there's also a fix for.

I found Matalak's solution on the forum which worked for my machine and opened a bug report to try to bring attention to the small number of machines that seem to be affected in this way.

Although it's not an accurate number of how many people are affected, it looks like it affects 13 people so far :)

I suspect if more people were experiencing this issue then there'd have been an update to fix it or a mention in the release notes.

Thanks for the response. I'm on last year's model with a Core i5-7300U CPU @ 2.60GHz.

A couple further notes for me: It seems some users are reporting 100% repeatable failures. Mine are intermittent; so, it's a bit harder to tell if things have started working again.

My failure mode might be slightly different as well. Sometimes, the machine fails to go in to a suspend. In this case, it starts to go to sleep, gives me a "greyed out" screen (screen goes blank but doesn't turn off) with a cursor, and stays there for several minutes and then pops up at the login prompt. This is obnoxious, but at least hasn't led to data loss and is reasonably easy to recognize.

The second failure mode is more like you describe and is much more serious. The machine appears to have gone to sleep (screen turns off, not sure about other indicators. I don't normally pay attention to them). I put it in my bag, take it out, and at least one occasion realize it has been running because it's hot (though there were other failures where I didn't notice this, but then I was also biking through a chilly night, so maybe that kept it cool?) It does not wake up, and a forced shutdown with the power button is required.

About a week ago, I installed the tlp package with --install-suggests, which might be a contributor? I'm sure I experienced at least one of the "greyed out" failures prior to that, but I don't think any of the "black out/hard lock" failures, though I only upgraded to 18.04 about 2 weeks ago.

Started a thread on the Ubuntu Forums for troubleshooting and more extended discussion to try to keep the bug report more succinct and on-topic: https://ubuntuforums.org/showthread.php?t=2395562

Sorry for the late reply.

Can you make sure hibernation was affected by commit a192aa923b66a435aae56983c4912ee150bc9b32?

Please do the following:

$ git checkout a192aa923b66a435aae56983c4912ee150bc9b32
...then build and try the kernel

$ git checkout a192aa923b66a435aae56983c4912ee150bc9b32^
...then build and try the kernel without the commit

@kaihengfeng - no problem, here's the results:

First kernel (with the commit) - Hibernation starts but then system seizes with power LED on requiring forced shutdown. Upon restart, hibernation resumes from where you left off as if nothing went wrong.

Second kernel (without the commit) - Hibernation starts and shutsdown by itself. Upon restart, hibernate resumes as expected.

In both cases, hibernation is resuming without issue but with the first kernel (with the commit) a forced shutdown is required. Machine will 'hang' indefinitely with the screen off and the power LED on.

Please try this kernel with latest patch from Rafael for testing:
https://people.canonical.com/~khfeng/lp1774950-s4/

Both suspend and hibernate work for me now with the new kernel.

Resume from suspend works for me again, with kernel 4.15.0-29 that i got updated to from repo.

Tested kernel with lastest patch on HP Pavilion with Intel Pentium N3540 - suspend & hibernate work fine with both Ubuntu & Kubuntu 18.04

After a few successful suspend/hibernates, hibernate didn't shut down the machine properly this morning and it then didn't resume after a forced shutdown. This is on an Acer Tavelmate B115 (Intel Pentium N3540 CPU)

Laptop: Lenovo Thinkpad T430 with intel GPU

The patched kernel https://people.canonical.com/~khfeng/lp1774950/ seems to fix the problem.
I tried few hybrid-sleep cycles, it works by filling in the swap partition:

wibru@shablagoo ~ $ cat /etc/initramfs-tools/conf.d/resume
RESUME=UUID=1c64e295-5694-44d9-a9ab-768b8196daa9

wibru@shablagoo ~ $ grep resume /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=1c64e295-5694-44d9-a9ab-768b8196daa9"

Thanks,

Confirmed that Rafael's patched kernel fixes the issue on an Asus Zenbook UX303LA which exhibited the same problem that the OP described (issue occured with at least 4.15 and 4.17) on Ubuntu 16.04. I tested the suspend function with the patched kernel over two days.

Status changed to 'Confirmed' because the bug affects multiple users.

I had same symptoms as described earlier in this bug and Rafael's patched kernel fixed it (https://people.canonical.com/~khfeng/lp1774950-s4/).

Thank you- the suspend problem was really annoying.

Is there a way to determine, or be notified of, which kernel that patch will land in?

Thanks again!

Reression one: https://bugzilla.kernel.org/show_bug.cgi?id=198631#c16

Regression two: https://bugzilla.kernel.org/show_bug.cgi?id=200717

I'm also having this same issue on my Dell XPS15. I'm running kernel 4.18.0-rc8 but no luck.

Stephen, XPS 15 is unlikely to be affected by this bug.
Please file a new one, thanks!

This is strange, I also have it on my XPS 15 (9560), exactly the same as described here with the same behavior: it worked on kernels before 4.15.

@smustgrave and @ariake - I've attempted to cover some of the other suspend issues I found whilst trying to work out where my machine was going wrong in the first post here - https://ubuntuforums.org/showthread.php?t=2395562

The XPS is tricky because there were some XPS suspend issues related to s2idle (https://askubuntu.com/questions/1029474/ubuntu-18-04-dell-xps13-9370-no-longer-suspends-on-lid-close/1036122#1036122) and it also has nVidia graphics which had a buggy nouveau driver (don't know if it's been fixed yet) or could be an issue with the proprietary drivers. s2idle issues and nVidia nouveau problem exhibited similar behaviour.

I'll be happy to try to help troubleshoot over on the Ubuntu forum thread and hopefully you won't need the patched kernel to get suspend working properly again.

Hello, is there a release which has the fix committed? Because I wanted to try the patched kernel with non-free nvidia drivers (390) are they compatible?. When installing it with dpkg, the machine says that the kernel-image gives conflict with the present one (last 18.04 kernel). I apologize for my newbie knowledge.

@yeboster - it's possible that you might not need the patched kernel to get suspend to work. Please see here for troubleshooting and to discuss further: https://ubuntuforums.org/showthread.php?t=2395562

I can confirm that the fix in the Cosmic kernel is sufficient. Will this be backported to Bionic and Xenial HWE?

Using the Ubuntu Kernel Update Utility, I've tried Kubuntu 18.04 with the 4.17.14 kernel and suspend and hibernate both work fine on HP Pavilion with Intel Pentium N3540.

(UKUU details here: https://www.omgubuntu.co.uk/2017/02/ukuu-easy-way-to-install-mainline-kernel-ubuntu - 4.18 kernel is also available but haven't tried that yet)

This bug was fixed in the package linux - 4.17.0-7.8

---------------
linux (4.17.0-7.8) cosmic; urgency=medium

  * linux: 4.17.0-7.8 -proposed tracker (LP: #1785242)

  * Cosmic update to 4.17.12 stable release (LP: #1785211)
    - spi: spi-s3c64xx: Fix system resume support
    - Input: elan_i2c - add ACPI ID for lenovo ideapad 330
    - Input: i8042 - add Lenovo LaVie Z to the i8042 reset list
    - Input: elan_i2c - add another ACPI ID for Lenovo Ideapad 330-15AST
    - mm: disallow mappings that conflict for devm_memremap_pages()
    - kvm, mm: account shadow page tables to kmemcg
    - delayacct: fix crash in delayacct_blkio_end() after delayacct init failure
    - tracing: Fix double free of event_trigger_data
    - tracing: Fix possible double free in event_enable_trigger_func()
    - kthread, tracing: Don't expose half-written comm when creating kthreads
    - tracing/kprobes: Fix trace_probe flags on enable_trace_kprobe() failure
    - tracing: Quiet gcc warning about maybe unused link variable
    - arm64: fix vmemmap BUILD_BUG_ON() triggering on !vmemmap setups
    - drm/i915/glk: Add Quirk for GLK NUC HDMI port issues.
    - mlxsw: spectrum_switchdev: Fix port_vlan refcounting
    - kcov: ensure irq code sees a valid area
    - mm: check for SIGKILL inside dup_mmap() loop
    - drm/amd/powerplay: Set higher SCLK&MCLK frequency than dpm7 in OD (v2)
    - xen/netfront: raise max number of slots in xennet_get_responses()
    - hv_netvsc: fix network namespace issues with VF support
    - skip LAYOUTRETURN if layout is invalid
    - ixgbe: Fix setting of TC configuration for macvlan case
    - ALSA: emu10k1: add error handling for snd_ctl_add
    - ALSA: fm801: add error handling for snd_ctl_add
    - NFSv4.1: Fix the client behaviour on NFS4ERR_SEQ_FALSE_RETRY
    - nfsd: fix error handling in nfs4_set_delegation()
    - nfsd: fix potential use-after-free in nfsd4_decode_getdeviceinfo
    - vfio: platform: Fix reset module leak in error path
    - vfio/mdev: Check globally for duplicate devices
    - vfio/type1: Fix task tracking for QEMU vCPU hotplug
    - kernel/hung_task.c: show all hung tasks before panic
    - mem_cgroup: make sure moving_account, move_lock_task and stat_cpu in the
      same cacheline
    - mm: /proc/pid/pagemap: hide swap entries from unprivileged users
    - mm: vmalloc: avoid racy handling of debugobjects in vunmap
    - mm/slub.c: add __printf verification to slab_err()
    - rtc: ensure rtc_set_alarm fails when alarms are not supported
    - rxrpc: Fix terminal retransmission connection ID to include the channel
    - perf tools: Fix pmu events parsing rule
    - netfilter: ipset: forbid family for hash:mac sets
    - netfilter: ipset: List timing out entries with "timeout 1" instead of zero
    - irqchip/ls-scfg-msi: Map MSIs in the iommu
    - watchdog: da9063: Fix updating timeout value
    - media: arch: sh: migor: Fix TW9910 PDN gpio
    - printk: drop in_nmi check from printk_safe_flush_on_panic()
    - bpf, arm32: fix inconsistent naming about emit_a32_lsr_{r64,i64}
    - ceph: fix alignment of rasize
    - ceph: fix use-after-free in ceph_statfs()
    - e1000e: Ignore TSYNCRXCTL when getting I219...

Greetings to the subscribers of soon-closed bug, here's my 50 kopecks.
My laptop is Acer Aspire E5-511-P6CS, Pentium N3540 (Bay Trail), 4+4GB RAM, originally WD10JPVX (HDD!), which is currently in an optibay and I have Linux Mint 19 running off of ADATA SU800 250GB.
I assume that the commit in question somewhat broke ACPI handling for Bay Trails, as my machine is affected: hangs upon suspend to RAM, power LED doesn't switch to blinking orange but stays lit blue, and UEFI starts kicking the fan in case cpu got stuck. Since 4.15 tried uswsusp and pm-utils to no avail. intel_idle.max_cstate=1 active.
As soon as I saw that bot post announcing 4.17.0-7.8 from cosmic, I decided to manually dpkg -i the kernel onto bionic (Tara uses 4.15.0-32), and after a reboot the laptop happily suspends and quickly wakes back upon ex. keypresses. Suspend is handled by systemd, pm-utils are installed, uswsusp isn't.
So when would this arrive to Canonical's linux-4.15 LTS branch? (bionic-updates, bioniic-security)

I tried kernel 4.17.0-7.8 from cosmic on Ubuntu bionic and got some issues. After installing the 4.17 kernel, I tested my PC and found it can hibernate normally. But, later on I found the kernel was not compatible with Nvidia-driver 390.48 that was from Ubuntu bionic release. Purging and reinstalling the driver did not help. Then I added pa:graphics-drivers/ppa to install nvidia-390 (390.77) and it worked with 4.17.0-7.8 on Bionic. However, the hibernation problem came back and had exactly the same behaviour as before: the machine hanged on hibernation, my monitor went to sleep, the machine was still on(power button LED on and fans on), no response. I had to do hard reset.

I can confirm the "nouveau.modeset=0" trick seems to be working for me so far (meaning, I am able to suspend the system again).

I upgraded from 16.04 two days ago - suspend has been working fine for the entire lifetime of the 16.04 install.

A colleague has also reported suspend/hibernate problems on her new windows-based machine,also with nVidia screen card. Strange.

Hardware:
MSI Ge62 2QE Apache Pro
Intel Core i7
nVidia GTX965M

`uname -r` :
4.15.0-32-generic

`lsb_release --all` :
LSB Version: core-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic

`lshw -c video | grep configuration`
       configuration: driver=nvidia latency=0
       configuration: driver=i915 latency=0

` modinfo nvidia`:
filename: /lib/modules/4.15.0-32-generic/updates/dkms/nvidia.ko
alias: char-major-195-*
version: 390.48
supported: external
license: NVIDIA
srcversion: FA33B00C00A6F70EC9CF314
alias: pci:v000010DEd00000E00sv*sd*bc04sc80i00*
alias: pci:v000010DEd*sv*sd*bc03sc02i00*
alias: pci:v000010DEd*sv*sd*bc03sc00i00*
depends: ipmi_msghandler
retpoline: Y
name: nvidia
vermagic: 4.15.0-32-generic SMP mod_unload
parm: NVreg_Mobile:int
parm: NVreg_ResmanDebugLevel:int
parm: NVreg_RmLogonRC:int
parm: NVreg_ModifyDeviceFiles:int
parm: NVreg_DeviceFileUID:int
parm: NVreg_DeviceFileGID:int
parm: NVreg_DeviceFileMode:int
parm: NVreg_UpdateMemoryTypes:int
parm: NVreg_InitializeSystemMemoryAllocations:int
parm: NVreg_UsePageAttributeTable:int
parm: NVreg_MapRegistersEarly:int
parm: NVreg_RegisterForACPIEvents:int
parm: NVreg_CheckPCIConfigSpace:int
parm: NVreg_EnablePCIeGen3:int
parm: NVreg_EnableMSI:int
parm: NVreg_TCEBypassMode:int
parm: NVreg_UseThreadedInterrupts:int
parm: NVreg_EnableStreamMemOPs:int
parm: NVreg_EnableBacklightHandler:int
parm: NVreg_EnableUserNUMAManagement:int
parm: NVreg_EnableIBMNPURelaxedOrderingMode:int
parm: NVreg_MemoryPoolSize:int
parm: NVreg_IgnoreMMIOCheck:int
parm: NVreg_RegistryDwords:charp
parm: NVreg_RegistryDwordsPerDevice:charp
parm: NVreg_RmMsg:charp
parm: NVreg_AssignGpus:charp

@hendrikc could you confirm if the hibernation works on your system? I got 4.15.0-33-generic and nvidia-390.48, nvidia 1080ti, i7, I can suspend the system but not hibernate.

Same issue with a Lenovo T480s with Intel graphics. Blank screen upon resume after suspend. Mouse cursor works, can CTL+ALT+F1 to a command prompt. Was working properly until last week, but had this issue 2 times over 2 days. Machine is routinely kept up to date.

Hardware:
Intel(R) Core(TM) i7-8650U
Integrated Intel® UHD Graphics 620
1 TB PCIe SSD

uname -r:
4.15.0-33-generic

OS:
Kubuntu 18.04
plasmashell 5.12.6

This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed-bionic'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

I can confirm that

Package: linux-image-4.15.0-34-generic
Architecture: amd64
Version: 4.15.0-34.37

fixes the problem for me.

Both suspend and hibernate have been tested on an Acer Travelmate B115M (with Intel Pentium N3540 CPU)

I upgraded the kernel from 4.15.0-33 to 4.17.14 and it did not help much. Now, after opening the lid the screen works for a second before its getting dark again.

Its a HP Probook 470 with i7 8550 CPU, 250GB SSDdrive and Intel UHD Graphics 620. Ubuntu 18.04

For me, the same issue remains but I suspect it is related to Nvidia driver, since after I removed nvidia driver, both suspend and hibernate work normal with this new kernel. I used the proprietary tested Nvidia-390.48 driver on Nvidia 1080.

With this new kernel, I tested hibernate with the open source driver coming with ubuntu. S2Disk seems to work fine but the machine hanged when resuming.

Followed helpful link from @brad-figg (Comment 85 - https://wiki.ubuntu.com/Testing/EnableProposed) to enable -proposed.

Link also explains how to enable -proposed but only update selected packages from it (i.e just the kernel from 4.15.0-33 to 4.15.0-34)

Re-tested 4.15.0-33 to check that Suspend still caused system to seize up and require a forced shutdown & then tested 4.15.0-34 where Suspend and Hibernate both work without issue.

Tested on HP Pavilion with Intel Pentium N3540 (Kubuntu 18.04 amd64)

@cmeerw - thanks for updating the tag to verification-done-bionic - much appreciated

Hi,
my notebook is a Dell Inspiron 15R with Intel i7 processor and AMD Radeon. I've updated to ubuntu 18.04 and I'm facing the suspend problem: it suspends but after a time it turns off.

Would the fix on this issue also affect my machine?

Hi @cvgaviao - I don't think it'll be related but there'll be a standard system update to kernel 4.15.0-34 available soon so you can see if the behaviour changes. Feel free to discuss further here: https://ubuntuforums.org/showthread.php?t=2395562

On my Acer Aspire ES-512 suspend as well as hibernate freeze the kubuntu 18.04 that I installed the day before yesterday on a 18G deleted partition.

The latest kernel where suspend and hibernate work is 3.17, which however has problems with touchpad. That is, I use 3.16.57. From 3.18 and all later kernels suspend and hibernate do not work.

It does not help that I change /etc/default/grup adding RESUME=UUID=<uuid of swap> or nouveau.modeset=0 to GRUB_CMDLINE_LINUX. Nor does it help that I enable hibernate in /var/lib/polkit-1/localauthority/10-vendor.d/com.ubuntu.desktop.pkla. Feng's fixed kernel did not work either (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950/comments/61).

If anyone want additional information, just let me know.

I have tried the following kernels:

Found installed: 3.17.1-031701.201410150735
Found installed: 3.18.120-0318120.201808280231
Found installed: 4.15.0.33.35
Found installed: 3.18.18-031818.201507101433
Found installed: 4.15.0-33.36
Found installed: 3.16.45-031645.201707030336
Found installed: 4.18.5-041805.201808241320
Found installed: 3.18.1-031801.201412170637
Found installed: 3.18.36-031836.201606230133
Found installed: 4.15.0-29.31
Found installed: 4.1.11-040111.201510261146
Found installed: 3.17.8-031708.201501081837
Found installed: 4.14.41-041441.201806042208
Found installed: 3.16.57-031657.201806170831
Found installed: 3.18.2-031802.201501082011

uname -a
Linux baren 3.16.57-031657-generic #201806170831 SMP Sun Jun 17 08:33:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

lshw -short
H/W path Device Class Description
======================================================
                            system Aspire ES1-512 (EA53_BM_083D_1.09)
/0 bus Aspire ES1-512
/0/0 memory 64KiB BIOS
/0/4 processor Intel(R) Celeron(R) CPU N2840 @ 2.16GHz
/0/4/8 memory 32KiB L1 cache
/0/4/9 memory 1MiB L2 cache
/0/7 memory 24KiB L1 cache
/0/f memory 8GiB System Memory
/0/f/0 memory 8GiB SODIMM DDR3 Synchronous 1333 MHz (0,8 ns)
/0/f/1 memory SODIMM [empty]
/0/100 bridge Atom Processor Z36xxx/Z37xxx Series SoC Transaction Register
/0/100/2 display Atom Processor Z36xxx/Z37xxx Series Graphics & Display
/0/100/13 storage Atom Processor E3800 Series SATA AHCI Controller
/0/100/14 bus Atom Processor Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI
/0/100/14/0 usb3 bus xHCI Host Controller
/0/100/14/1 usb2 bus xHCI Host Controller
/0/100/14/1/3 bus USB2.0 Hub
/0/100/14/1/3/1 communication Atheros AR3012 Bluetooth
/0/100/14/1/3/2 input USB Receiver
/0/100/14/1/3/4 generic USB2.0-CRW
/0/100/14/1/4 multimedia VGA Webcam
/0/100/1a generic Atom Processor ...

If the acpi-lpss fix doesn't work for you, please file a new bug report.

Fixes for regressions from commentary #70: https://bugzilla.kernel.org/show_bug.cgi?id=198631#c22

@softrabbit - I have a machine with an Intel Celeron N2840 that oddly was never affected by the Suspend bug described in this report.

My HP Pavilion with N3540 and another I tested with an N2830 (using a Live USB of 18.04) were both affected but curiously not the N2840 machine.

I have started a thread regarding some of the Suspend issues on 18.04 that I found along the way whilst trying to figure out what was wrong with my machine. If you wish to discuss further please post here: https://ubuntuforums.org/showthread.php?t=2395562

This bug was fixed in the package linux - 4.15.0-34.37

---------------
linux (4.15.0-34.37) bionic; urgency=medium

  * linux: 4.15.0-34.37 -proposed tracker (LP: #1788744)

  * Bionic update: upstream stable patchset 2018-08-09 (LP: #1786352)
    - MIPS: c-r4k: Fix data corruption related to cache coherence
    - MIPS: ptrace: Expose FIR register through FP regset
    - MIPS: Fix ptrace(2) PTRACE_PEEKUSR and PTRACE_POKEUSR accesses to o32 FGRs
    - KVM: Fix spelling mistake: "cop_unsuable" -> "cop_unusable"
    - affs_lookup(): close a race with affs_remove_link()
    - fs: don't scan the inode cache before SB_BORN is set
    - aio: fix io_destroy(2) vs. lookup_ioctx() race
    - ALSA: timer: Fix pause event notification
    - do d_instantiate/unlock_new_inode combinations safely
    - mmc: sdhci-iproc: remove hard coded mmc cap 1.8v
    - mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register
    - mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus
    - libata: Blacklist some Sandisk SSDs for NCQ
    - libata: blacklist Micron 500IT SSD with MU01 firmware
    - xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent
    - drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros
    - arm64: lse: Add early clobbers to some input/output asm operands
    - powerpc/64s: Clear PCR on boot
    - IB/hfi1: Use after free race condition in send context error path
    - IB/umem: Use the correct mm during ib_umem_release
    - idr: fix invalid ptr dereference on item delete
    - Revert "ipc/shm: Fix shmat mmap nil-page protection"
    - ipc/shm: fix shmat() nil address after round-down when remapping
    - mm/kasan: don't vfree() nonexistent vm_area
    - kasan: free allocated shadow memory on MEM_CANCEL_ONLINE
    - kasan: fix memory hotplug during boot
    - kernel/sys.c: fix potential Spectre v1 issue
    - KVM: s390: vsie: fix < 8k check for the itdba
    - KVM: x86: Update cpuid properly when CR4.OSXAVE or CR4.PKE is changed
    - kvm: x86: IA32_ARCH_CAPABILITIES is always supported
    - powerpc/64s: Improve RFI L1-D cache flush fallback
    - powerpc/pseries: Restore default security feature flags on setup
    - powerpc/64s: Fix section mismatch warnings from setup_rfi_flush()
    - MIPS: generic: Fix machine compatible matching
    - mac80211: mesh: fix wrong mesh TTL offset calculation
    - ARC: Fix malformed ARC_EMUL_UNALIGNED default
    - ptr_ring: prevent integer overflow when calculating size
    - arm64: dts: rockchip: fix rock64 gmac2io stability issues
    - arm64: dts: rockchip: correct ep-gpios for rk3399-sapphire
    - libata: Fix compile warning with ATA_DEBUG enabled
    - selftests: sync: missing CFLAGS while compiling
    - selftest/vDSO: fix O=
    - selftests: pstore: Adding config fragment CONFIG_PSTORE_RAM=m
    - selftests: memfd: add config fragment for fuse
    - ARM: OMAP2+: timer: fix a kmemleak caused in omap_get_timer_dt
    - ARM: OMAP3: Fix prm wake interrupt for resume
    - ARM: OMAP2+: Fix sar_base inititalization for HS omaps
    - ARM: OMAP1: clock: Fix debugfs_create_*() usage
    - tls: retrun the correct IV in getsockopt
    - xhci: workaround for AMD Promontory disabled ports w...

4.16.0-041600-generic works for me in contrast to all of the 4.15 kernels that are shipped with Ubuntu. It also improves WiFi card handling of the 3x3ac QCA988x card tremendously, which often would disappear back when standby still worked. Now it not only appeared right on the first boot, but also continued to work throughout multiple standby cycles.

4.16 is a winner folks, thank you VERY much!

@da-bzzz Thank you. 4.16.0-041600-generic solved my problem. All other solutions mentioned in this thread did not work for me.

Bug still present Thinkpad X240 Ubuntu 18.04 – 4.15.0-36

Bug still present in 4.15.0-38-generic on HP Notebook - 15-ba047na.

$ uname -r
4.15.0-38-generic

$ 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: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 21
Model: 101
Model name: AMD A12-9700P RADEON R7, 10 COMPUTE CORES 4C+6G
Stepping: 1
CPU MHz: 1583.409
CPU max MHz: 2500.0000
CPU min MHz: 1300.0000
BogoMIPS: 4990.78
Virtualisation: AMD-V
L1d cache: 32K
L1i cache: 96K
L2 cache: 1024K
NUMA node0 CPU(s): 0-3
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate ssbd vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov

Tony, please file a new bug. AMD SoC doesn't use intel-lpss.

My Dell Latitude e7440 (core i7 4600U, intel graphics) shows a similar behaviour after updating to 18.04:

Wake-up after suspend often fails with power LED on. Hard shut down seems to be the only way to recover. Sometimes, additionally to this, suspend seems to incomplete in the sense that the laptop gets hot and the fan is running. The last entry in kern.log during the failing suspend is:

  PM: suspend entry (deep)

While the issue shows up often, I did not figure out how to deterministically triggers it.

I'm using the current kernel 4.15.0-38. Should this one contain the above discussed fix?

Carsten,

Yes the kernel has the fix.

So should I file a new bug report or should the status of this one be changed again?

Can I help by providing more information?

Please file a new bug.

Thanks for the information. I just filed bug #1801743.

I've noticed a similar problem with a Lenovo laptop with an Intel CPU, Intel Haswell graphics and an SSD. One difference is that suspend works fine the first time the lid is closed. Upon opening the lid, it comes back up and I can unlock the screen, but the touchpad no longer works. If I close the lid again, it never goes all the way into deep sleep. The symptoms are that the led that slowly blinks when it enters hibernate stays on all the time, so the battery drains quickly and it stays relatively hot. A hard reboot corrects the problem. This only appeared after upgrading to 18.04. The kernel version is 4.15.0-39.

I have same problem in Lenovo laptop with intel CPU, SSD.
With 16.04 it worked. In 18.04 it worked few days ago, now it doesn't work and using other kernel versions doesn't help, so I suspect it is not fault of newer kernel.

Same thing here – Thinkpad X240 (Intel graphics and SSD). Should we create a new bug?
In my case it is somehow correlated with ethernet. I can reproduce it in this way:
1. No WiFi connection only ethernet connection.
2. Suspend two times, after third time laptop won't suspend and ethernet stops working.

Bug still present Xiaomi Mi Notebook Pro Ubuntu 18.04.2 – 4.18.0-20-generic. Here I am using NVIDIA proprietary drivers for MX 150 GPU.

As I have describe above (#92), suspend did not work since kernel 3.16.57/3.17 on my Acer ES-512. A guy on ubuntuforum had found out that the problem disappeared when xHCI (external USB3.O controller) was turned off in the BIOS. The suspend problem also disappeared on my wife's laptop (another Acer Aspire).

Someone that is knowledgable about suspend, USB3.0 and changes after kernel 3.17 is perhaps able to figure out how to fix this bug.

I have this problem using a Dell Inspiron 7373 with Ubuntu 18.04 and 19.04

I have this problem using Alienware 17 R2 with Nvidia 970M Graphic card and ubuntu 19.04

I have a desktop with an i7-6900K and an NVidia 1060 card. For the issue is intermittent. It seems the longer the machine is asleep the less likely it is to wake. For example if it's suspended for 30m then it will usually wake. Any longer and it either reboots or the fans and lights stay on but it's dead, can't even ping it.

Kernel 4.15.0-72-generic.

I still have this or a similar issue. How do apply the patch?

Dell 5593-2721
Ubuntu 18.04.5 LTS

Problem appeared after updating kernel version to linux-image-5.4.0-58-generic.

I decided to rollback to previous image linux-image-5.0.0-1070-oem-osp1.

Its been 2 years, Current version of kernel is 5.4.* and still not fixed.
I have this problem from beginning (2019) & I don't have nvidia GPU.

I tried all except downgrading kernel.
Does anyone can tell which version I should test. I looked up but some said 4.14 works others 4.15.

I tried `v4.14.0-041400-generic` kernel, when I close & open lid it doesnt hang at all.
I left lid closed for hours & it woke up like charm.

But when I checked `/var/log/syslog` & `/var/log/kern.log` there was no text about suspending.
Not even single line was printed.

So I think its not entering suspend mode at all, but manages to turn off the screen & backlight.

Clicking suspend button or entering `sudo systemctl suspend` enters suspend mode & laptop gets stuck. holding power button is the only way to get back.

The `syslog` shows text related to suspending, here :
```
Feb 13 19:48:54 pc systemd[1]: Reached target Sleep.
Feb 13 19:48:54 pc systemd[1]: Starting Suspend...
Feb 13 19:48:54 pc systemd-sleep[2788]: Suspending system...
Feb 13 19:48:54 pc kernel: [ 6678.873054] PM: suspend entry (deep)
```

I tired another version `4.14.40-041440-generic` & closing lid enters suspend mode which causes hanging.

It seems `v4.14.0-041400-generic` is only one who doesn't have this problem.

If you want me to test any other version of kernel, feel free to ask.