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)

[pHeLiOn]

===SRU Justification===
[Impact]
Systems with acpi-lpss can't do S3/S4 on Bionic.

[Test]
Users confirmed these patches work for them.

[Fix]
Commit a192aa923b66a (ACPI / LPSS: Consolidate runtime PM and system
sleep handling) applies quirks for both runtime and system suspend.
This causes problems for some systems, so avoid using quirks on S3 and
S4.

[Regression Potential]
Low. These patches are in upstream stable, and it brings back driver's
old behavior.

===Original Bug Report===
I have installed Kubuntu 18.04 on 3 different machines (my friend's and my own) with no suspend problems but my HP Pavilion 11 x360 does not suspend.

It suspends fine with Ubuntu 17.10, Kubuntu 17.10, Devuan Jesse, Devuan ASCII and Windows 10 but fails with Ubuntu 18.04 and Kubuntu 18.04.

I have also tried suspend using a live USB of 18.04 on this machine and it fails in the same way, so does not appear to be caused by any additional programs that I had installed.

By installing an older kernel (4.14) on Kubuntu 18.04 the suspend function works as expected.

Running Kubuntu 18.04 with kernels 4.15, 4.16, 4.17 results in the suspend failure that freezes the machine and requires a hard reset.

Correct behaviour is -

Screen goes blank, fan goes off, power LED flashes to show machine is in suspend. Pressing power button triggers 'resume' function.

What happens -

Screen goes blank, fan stays on, power LED stays on. Machine stays in this state and does not respond to any keyboard interaction, mouse movement or power button presses.

Ctrl + Alt + f1 (or f2, f3, f4 etc) does not get any response.

The only way to use the machine is to shut down by holding down the power button.

Checking the logs suggests that the machine believes it is in suspend mode sleep [deep] when it isn't.

Having to hard reset to get any response means that the kernel logs say no more than sleep [deep]

pm-suspend also results in the same problems with kernels 4.15 and 4.16, but works fine with 4.14.

It is curious that a machine that suspends fine on an earlier 4.14 kernel no longer works with 4.15 and above, whilst 3 other machines (including one with pretty similar hardware) do not exhibit this problem.

There are only a handful of questions about it on the forums but at least 3 other people have the same problem:

https://askubuntu.com/questions/1029405/ubuntu-18-04-crashes-on-resuming-from-suspend

https://askubuntu.com/questions/1041369/after-upgrading-from-17-10-ubuntu-18-04-wont-sleep-suspend

I am attempting to round up anyone else with the same issue and point them to this bug report.

My laptop is HP Pavilion x360 11-n013na
Matalaks is Acer Aspire ES1-511
collisionTwo has XPS 9560

[Ubuntu Foundations Team Bug Bot (crichton)]

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.]

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

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.

[Joseph Salisbury (jsalisbury)]

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

[pHeLiOn (perryhelionsemail)]

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.

[pHeLiOn (perryhelionsemail)]

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.

[pHeLiOn (perryhelionsemail)]

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

[pHeLiOn (perryhelionsemail)]

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 )

[pHeLiOn (perryhelionsemail)]

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

[Matze (redroach)]

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 :)

[pHeLiOn (perryhelionsemail)]

@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.

[pHeLiOn (perryhelionsemail)]

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.

[pHeLiOn (perryhelionsemail)]

(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.)

[Kai-Heng Feng (kaihengfeng)]

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.

[pHeLiOn (perryhelionsemail)]

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

[pHeLiOn (perryhelionsemail)]

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?

[Mark Stosberg (markstos)]

This bug also affects the Dell XPS 13 9370.

[pHeLiOn (perryhelionsemail)]

@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.

[Jaroslaw Ilgiewicz (jarekil)]

@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.

[pHeLiOn (perryhelionsemail)]

@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!

[Fernando Consigli (ferconsigli)]

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.

[pHeLiOn (perryhelionsemail)]

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.

[Matalak (qwertzy-deactivatedaccount)]

@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 .

[cmeerw (cmeerw)]

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

[pHeLiOn (perryhelionsemail)]

@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 ;)

[Fernando Consigli (ferconsigli)]

@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.

[pHeLiOn (perryhelionsemail)]

@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? )

[pHeLiOn (perryhelionsemail)]

@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.

[pHeLiOn (perryhelionsemail)]

@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 :)

[Matalak (qwertzy-deactivatedaccount)]

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.

[cmeerw (cmeerw)]

@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).

[pHeLiOn (perryhelionsemail)]

@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.

[pHeLiOn (perryhelionsemail)]

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

[pHeLiOn (perryhelionsemail)]

@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 :) )

[pHeLiOn (perryhelionsemail)]

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.

[Kai-Heng Feng (kaihengfeng)]

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

[Matze (redroach)]

@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!

[pHeLiOn (perryhelionsemail)]

@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... :)

[cmeerw (cmeerw)]

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

[pHeLiOn (perryhelionsemail)]

@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!

[pHeLiOn (perryhelionsemail)]

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!

[Толстов Денис (tolstov-den)]

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)

[Lei Yu (yuleihit)]

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.

[demaniak (hendrikc)]

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

[Lei Yu (yuleihit)]

@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.

[milton hagler (miltonh26)]

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

[Brad Figg (brad-figg)]

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!

[cmeerw (cmeerw)]

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)

[Friedrich August (anfaenger)]

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

[Lei Yu (yuleihit)]

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.

[pHeLiOn (perryhelionsemail)]

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

[Cristiano Gavião (cvgaviao)]

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?

[pHeLiOn (perryhelionsemail)]

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

[Soft Rabbit (softrabbit)]

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 ...

[Kai-Heng Feng (kaihengfeng)]

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

[RussianNeuroMancer (russianneuromancer)]

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

[pHeLiOn (perryhelionsemail)]

@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

[Launchpad Janitor (janitor)]

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...

[Bzzz (da-bzzz)]

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!

[Lei Yu (yuleihit)]

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

[Jan (ijonfryderyk)]

Bug still present Thinkpad X240 Ubuntu 18.04 – 4.15.0-36

[Tony Corbett (g0wfv)]

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

[Kai-Heng Feng (kaihengfeng)]

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

[Carsten Gräser (graeser)]

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?

[Kai-Heng Feng (kaihengfeng)]

Carsten,

Yes the kernel has the fix.

[Carsten Gräser (graeser)]

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?

[Kai-Heng Feng (kaihengfeng)]

Please file a new bug.

[Carsten Gräser (graeser)]

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

[George White (co2isnotevil)]

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.

[Tommy_CZ (t-kijas)]

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.

[Jan (ijonfryderyk)]

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.

[Leonardo (leoemili)]

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.

[Soft Rabbit (softrabbit)]

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.

[Carlos Cesar Caballero Diaz (cccaballero)]

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

[Heber Uriegas (heberuriegas)]

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

[rabinnh (rab-nc83)]

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.

[Guus Ellenkamp (ellenkampguus)]

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

[PK (pk89)]

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.

[/tony/dev/null (tony-dev)]

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.

[/tony/dev/null (tony-dev)]

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.