Ubuntu 18.04 - Dell XPS13 9370 no longer suspends on lid close











up vote
34
down vote

favorite
18












This was working perfectly on 17.10 but after upgrading to 18.04 yesterday, when the lid is closed the screen turns off but doesn't suspend properly.



I travel around a lot and immediately noticed the heat (and battery draining) when taking it out of the travel case.



I've tried uncommenting these lines in /etc/systemd/logind.conf



HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend


and restarted but didn't make any difference.










share|improve this question


















  • 4




    Voting up because I have the same issue on 18.04 as of a couple days ago. Previously was on 17.04. On a Dell XPS15. Can you check to see if your suspend (i.e., just running suspend without closing the lid) also doesn't work properly? If so, same issue here.
    – collisionTwo
    Apr 30 at 17:56










  • @collisionTwo same here. Dell XPS 9560, 18.04. Clicking "Suspend" does not actually suspend the system, it shuts it down.
    – karlgrz
    Apr 30 at 22:24










  • I had previously used the hack mentioned here on 16.04, worked great, might have to revert to that. Was hoping to avoid it but /shrug: karlgrz.com/dell-xps-15-ubuntu-tweaks
    – karlgrz
    Apr 30 at 22:25






  • 1




    I might play around with that hack. Strange thing was things worked completely fine for me on 17.04. My problem is slightly different - when I "suspend", either manually or by closing the lid, it turns off the screen and keyboard light, but the fans stay on, the power light stays on, and trying to wake it up from this state doesn't work at all.
    – collisionTwo
    Apr 30 at 22:28






  • 1




    @collisionTwo yes, you're right. It happens when manually suspending too!
    – Murray
    May 1 at 6:06















up vote
34
down vote

favorite
18












This was working perfectly on 17.10 but after upgrading to 18.04 yesterday, when the lid is closed the screen turns off but doesn't suspend properly.



I travel around a lot and immediately noticed the heat (and battery draining) when taking it out of the travel case.



I've tried uncommenting these lines in /etc/systemd/logind.conf



HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend


and restarted but didn't make any difference.










share|improve this question


















  • 4




    Voting up because I have the same issue on 18.04 as of a couple days ago. Previously was on 17.04. On a Dell XPS15. Can you check to see if your suspend (i.e., just running suspend without closing the lid) also doesn't work properly? If so, same issue here.
    – collisionTwo
    Apr 30 at 17:56










  • @collisionTwo same here. Dell XPS 9560, 18.04. Clicking "Suspend" does not actually suspend the system, it shuts it down.
    – karlgrz
    Apr 30 at 22:24










  • I had previously used the hack mentioned here on 16.04, worked great, might have to revert to that. Was hoping to avoid it but /shrug: karlgrz.com/dell-xps-15-ubuntu-tweaks
    – karlgrz
    Apr 30 at 22:25






  • 1




    I might play around with that hack. Strange thing was things worked completely fine for me on 17.04. My problem is slightly different - when I "suspend", either manually or by closing the lid, it turns off the screen and keyboard light, but the fans stay on, the power light stays on, and trying to wake it up from this state doesn't work at all.
    – collisionTwo
    Apr 30 at 22:28






  • 1




    @collisionTwo yes, you're right. It happens when manually suspending too!
    – Murray
    May 1 at 6:06













up vote
34
down vote

favorite
18









up vote
34
down vote

favorite
18






18





This was working perfectly on 17.10 but after upgrading to 18.04 yesterday, when the lid is closed the screen turns off but doesn't suspend properly.



I travel around a lot and immediately noticed the heat (and battery draining) when taking it out of the travel case.



I've tried uncommenting these lines in /etc/systemd/logind.conf



HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend


and restarted but didn't make any difference.










share|improve this question













This was working perfectly on 17.10 but after upgrading to 18.04 yesterday, when the lid is closed the screen turns off but doesn't suspend properly.



I travel around a lot and immediately noticed the heat (and battery draining) when taking it out of the travel case.



I've tried uncommenting these lines in /etc/systemd/logind.conf



HandleLidSwitch=suspend
HandleLidSwitchDocked=suspend


and restarted but didn't make any difference.







suspend 18.04 xps






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Apr 29 at 0:24









Murray

193127




193127








  • 4




    Voting up because I have the same issue on 18.04 as of a couple days ago. Previously was on 17.04. On a Dell XPS15. Can you check to see if your suspend (i.e., just running suspend without closing the lid) also doesn't work properly? If so, same issue here.
    – collisionTwo
    Apr 30 at 17:56










  • @collisionTwo same here. Dell XPS 9560, 18.04. Clicking "Suspend" does not actually suspend the system, it shuts it down.
    – karlgrz
    Apr 30 at 22:24










  • I had previously used the hack mentioned here on 16.04, worked great, might have to revert to that. Was hoping to avoid it but /shrug: karlgrz.com/dell-xps-15-ubuntu-tweaks
    – karlgrz
    Apr 30 at 22:25






  • 1




    I might play around with that hack. Strange thing was things worked completely fine for me on 17.04. My problem is slightly different - when I "suspend", either manually or by closing the lid, it turns off the screen and keyboard light, but the fans stay on, the power light stays on, and trying to wake it up from this state doesn't work at all.
    – collisionTwo
    Apr 30 at 22:28






  • 1




    @collisionTwo yes, you're right. It happens when manually suspending too!
    – Murray
    May 1 at 6:06














  • 4




    Voting up because I have the same issue on 18.04 as of a couple days ago. Previously was on 17.04. On a Dell XPS15. Can you check to see if your suspend (i.e., just running suspend without closing the lid) also doesn't work properly? If so, same issue here.
    – collisionTwo
    Apr 30 at 17:56










  • @collisionTwo same here. Dell XPS 9560, 18.04. Clicking "Suspend" does not actually suspend the system, it shuts it down.
    – karlgrz
    Apr 30 at 22:24










  • I had previously used the hack mentioned here on 16.04, worked great, might have to revert to that. Was hoping to avoid it but /shrug: karlgrz.com/dell-xps-15-ubuntu-tweaks
    – karlgrz
    Apr 30 at 22:25






  • 1




    I might play around with that hack. Strange thing was things worked completely fine for me on 17.04. My problem is slightly different - when I "suspend", either manually or by closing the lid, it turns off the screen and keyboard light, but the fans stay on, the power light stays on, and trying to wake it up from this state doesn't work at all.
    – collisionTwo
    Apr 30 at 22:28






  • 1




    @collisionTwo yes, you're right. It happens when manually suspending too!
    – Murray
    May 1 at 6:06








4




4




Voting up because I have the same issue on 18.04 as of a couple days ago. Previously was on 17.04. On a Dell XPS15. Can you check to see if your suspend (i.e., just running suspend without closing the lid) also doesn't work properly? If so, same issue here.
– collisionTwo
Apr 30 at 17:56




Voting up because I have the same issue on 18.04 as of a couple days ago. Previously was on 17.04. On a Dell XPS15. Can you check to see if your suspend (i.e., just running suspend without closing the lid) also doesn't work properly? If so, same issue here.
– collisionTwo
Apr 30 at 17:56












@collisionTwo same here. Dell XPS 9560, 18.04. Clicking "Suspend" does not actually suspend the system, it shuts it down.
– karlgrz
Apr 30 at 22:24




@collisionTwo same here. Dell XPS 9560, 18.04. Clicking "Suspend" does not actually suspend the system, it shuts it down.
– karlgrz
Apr 30 at 22:24












I had previously used the hack mentioned here on 16.04, worked great, might have to revert to that. Was hoping to avoid it but /shrug: karlgrz.com/dell-xps-15-ubuntu-tweaks
– karlgrz
Apr 30 at 22:25




I had previously used the hack mentioned here on 16.04, worked great, might have to revert to that. Was hoping to avoid it but /shrug: karlgrz.com/dell-xps-15-ubuntu-tweaks
– karlgrz
Apr 30 at 22:25




1




1




I might play around with that hack. Strange thing was things worked completely fine for me on 17.04. My problem is slightly different - when I "suspend", either manually or by closing the lid, it turns off the screen and keyboard light, but the fans stay on, the power light stays on, and trying to wake it up from this state doesn't work at all.
– collisionTwo
Apr 30 at 22:28




I might play around with that hack. Strange thing was things worked completely fine for me on 17.04. My problem is slightly different - when I "suspend", either manually or by closing the lid, it turns off the screen and keyboard light, but the fans stay on, the power light stays on, and trying to wake it up from this state doesn't work at all.
– collisionTwo
Apr 30 at 22:28




1




1




@collisionTwo yes, you're right. It happens when manually suspending too!
– Murray
May 1 at 6:06




@collisionTwo yes, you're right. It happens when manually suspending too!
– Murray
May 1 at 6:06










4 Answers
4






active

oldest

votes

















up vote
37
down vote



accepted










I think I managed to figure out what was going on, thanks to these two sources: Dell XPS 13 (9370) ArchLinux Install notes and Arch Linux Forum.



For some reason, the laptop is not going in deep sleep anymore, but rather an s2idle mode which is merely a screen off type of suspend.



Diagnosis of the issue



To confirm whether this is the case for your system, suspend the laptop using your favorite method (close the lid, hit Fn+End, write pm-suspend in a terminal if you have pm-utils installed, or hit the Windows key type suspend and hit the Enter key).



Wake up from suspend mode and type in a terminal: sudo journalctl | grep "PM: suspend" | tail -2.
If the output is



May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
May 13 20:52:36 mex kernel: PM: suspend exit


Then you are not entering deep sleep.
You can also check cat /sys/power/mem_sleep which should return



[s2idle] deep


which confirms that the default suspend mode is s2idle (since it is highlighted with brackets).



Temporary fix



To try a temporary fix, do echo deep > /sys/power/mem_sleep as a root user. Check that it was successful by looking at the output of cat /sys/power/mem_sleep which should be



s2idle [deep]


then suspend the laptop and wake up again. If sudo journalctl | grep "PM: suspend" | tail -2 returns



May 13 18:41:00 mex kernel: PM: suspend entry (deep)
May 13 20:52:36 mex kernel: PM: suspend exit


then the issue should be fixed.
You can put your computer to sleep for a couple of hours and check whether the battery drain improved.



Permanent fix



To make it permanent, you have to edit your bootloader cmdline. To do so, edit as root user the file /etc/default/grub, by running for example sudo -H gedit /etc/default/grub. Replace the line



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


with



GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"


and regenerate your grub configuration (run sudo grub-mkconfig -o /boot/grub/grub.cfg).






share|improve this answer



















  • 1




    Alternative permanent fix, that doesn't involve changing kernel parameters: Install sysfsutils and echo 'power/mem_sleep = deep' > /etc/sysfs.d/mem_sleep.conf. sysfsutils is a tiny service that just restores sysfs parameters like this.
    – StrangeNoises
    May 17 at 11:30












  • This method certainly works, however it exposes another problem. It seems the bluetooth adapter isn't able to reliably wake up (it usually disappears for me after the second such sleep). This is a known problem described and possibly fixed here, where for the 9360 they've added a quirk to reset the adapter on resume. Looks like it'll be in 4.17. workaround btusb.enable_autosuspend=n only appears in 4.16 so we can't use that yet either. May have to install Fedora to join that conversation and confirm same fix for 9370 would work.
    – StrangeNoises
    May 18 at 16:58






  • 2




    I love this in depth answer, but in ubuntu 18 I'm getting issues at the echo deep step, wherein I'm getting an echo: write error: Invalid argument. This may be because i'm not in root properly. I can't su - because ubuntu has it disabled, so I tried both sudo -i and sudo su
    – Caleb Jay
    Jul 29 at 22:31






  • 1




    On Dell XPS 13 (9370), deep suspend mode doesn't work properly if disk encryption is enabled on Ubuntu 18.04. dell.com/community/XPS/…
    – Akihiro HARAI
    Aug 29 at 1:51






  • 1




    @CalebJay: Ubuntu spells su - as sudo -i. You can also change the root password with sudo passwd, if that's the way you prefer to administer your Unix boxes.
    – hackerb9
    Oct 22 at 4:19




















up vote
8
down vote













Try creating /etc/systemd/sleep.conf:



[Sleep]
SuspendMode=
SuspendState=mem


And reboot. This seems to be working for me, although I'm not certain I didn't also get improvement with the /etc/systemd/logind.conf change I did first. In any case, no heat or fan noise is observed while suspended with the lid shut, and it doesn't respond to ping over wifi either, which I had been getting, intermittently, before.



Battery life still goes down while suspended, probably because the working method of suspend is just less efficient than the default, ideal, method that apparently isn't working properly, but it appears better than the default behaviour.



Tried on my XPS 13 9370, I don't know about older models, although it seems likely they'll be similar.



I had tried installing pm-utils and using pm-suspend and that seemed to be suspending pretty effectively, so I wanted to see if I could make systemd-suspend do the same thing.



I looked through the scripts in pm-utils to figure out what it was actually doing, and it looks like, in this situation, it was doing echo -n "mem" > /sys/power/state. So I created the /etc/systemd/sleep.conf file as shown above to match it.



It's not entirely clear what the default behaviour is. The manpage for systemd-sleep.conf says that the distro should include /etc/systemd/sleep.conf with the compiled-in defaults commented out, so you can see this information, but in ubuntu this file is missing. I noticed though that if you cat /sys/power/state you get:



freeze mem


So I'm guessing that this is what it's doing by default. My guess is that freeze may be being accepted, in that it doesn't throw an error, which would otherwise cause systemd to move on to mem, but maybe doesn't actually work properly, or reliably, for complex reasons we seem unable to determine. So just sending mem instead is a hopeful stab at avoiding that and just doing what pm-suspend does.



I suspect the SuspendMode setting is actually superfluous and doesn't do anything anyway. I suspect this because cat /sys/power/disk just gets you:



[disabled]


Am new user, thus unable to comment with an observation, forced to present it as an answer as if I'm super-confident in it! But I think it's working.






share|improve this answer





















  • Before trying your changes my $ cat /sys/power/disk revealed: [platform] shutdown reboot suspend test_resume
    – WinEunuuchs2Unix
    May 14 at 2:54


















up vote
3
down vote













The other answers here are excellent, in-depth and well researched.



Unfortunately they didn't work for my particular machine :(



If you have nVidia graphics, there seems to be a fix that is working for a good number of people, helpfully provided by cascagrossa in the answer to this question: Ubuntu 18.04 crashes on resuming from suspend



It is suspected to be a buggy nouveau driver and can sort out suspend issues by adding nouveau.modeset=0 to grub and has been confirmed in the comments for helping fix the issue for others too.



I've got Intel graphics on my problem machine and curiously I've had no suspend problems with Ubuntu or Kubuntu 18.04 on at least 3 other machines (my friend's and my own), so why this particular machine is being such a douche about it is unclear.



I recommend anyone experiencing this sort of issue to follow these steps to help identify the problem:




  1. Do you have nVidia graphics? If so, try the nouveau.modeset=0 grub trick.



  2. Check that suspend works at all. If you are closing the lid and then opening it up later and it's not waking up, it may seem like it's failing to 'resume'.




    • You should be able to manually select suspend on any desktop but it's slightly hidden in Gnome Shell - you can either longpress the power button from the top right hand menu of the screen, or click that button whilst holding Alt or press the Super key and type in 'suspend'


    • By selecting suspend you can check that the screen has switched off, the power LED is flashing as it should and you'd expect that any fan running will also stop. If all this happens but then you can't get your machine to waken up then it would appear to be a 'resume' problem rather than a 'suspend' problem.


    • My issue has been that it's not actually going into suspend and Murray who asked the original question, when asked by collisionTwo to check this, realised the problem was arising when manually suspending too.


    • In my case (on the one problem laptop), the screen goes blank but the power LED stays on and if the fan is running it continues to run. The machine does not respond to any keypresses, touchpad movement or clicks or power button presses. The only thing that can be done is to shut it down.


    • I've tried playing music whilst going into suspend (to check that it's not just the screen going blank) but the music stops and the machine has basically seized up.





  3. Try your machine with a Live USB of 18.04 and check if you have similar suspend issues.




    • This will just confirm that the suspend issues are not to do with any additional programs that you have installed.


    • In my case I suspected it was because I had installed tlp which might have been interfering with the suspend mode somehow, but the same behaviour occurred with a Live USB of both Ubuntu 18.04 and Kubuntu 18.04





  4. Try out the other two well researched solutions provided here by monty47 and StrangeNoises and see if you get good results.




    • They seem to have helped a number of people get suspend back up and running properly on 18.04 and may be more to do with the machine going into an s2idle state rather than the sleep (deep) mode of a usual 'suspend'.




  5. If none of the solutions are working to resolve your suspend issues on 18.04 then try the accepted answer to this: Ubuntu 18.04 crashes on resuming from suspend




    • The provided solution by Matalak (who also asked the question) was to use UKUU to try an older 4.14 kernel.


    • My problem machine had no suspend issues with Ubuntu 17.10 and Kubuntu 17.10, so it makes sense since 17.10 uses the 4.14 kernel. It now suspends fine in both Ubuntu 18.04 and Kubuntu 18.04 using the 4.14 kernel.





  6. If you tried the other solutions and could only fix your suspend issues by going back to a 4.14 kernel, you might be interested in the bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950




    • It appears to only be affecting a few machines with a specific combination of hardware and can be difficult to identify in amongst other nouveau related problems or s2idle issues.


    • It seems to be more prevalent for those running a Bay Trail Atom Celeron/Pentium but others have reported a similar issue with other machines.


    • If you are able to check your kern.log after this failed suspend (i.e once you've had to shut down your machine and restart) you might notice it says PM: suspend entry (deep) and then you have no further entries apart from the many lines of booting up again.


    • There is currently a patch that seems to resolve the issue.


    • If you feel like adding your voice to the bug report, it would be interesting to see which particular machines are affected (and check that the patch fixes the issue for everyone).





Also attempting to gather 'Suspend Issues in 18.04' together in this thread: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724






share|improve this answer






























    up vote
    1
    down vote













    Just want to add an answer to users of Thinkpad X1 Carbon 6th Gen which has a similar symptom i.e. battery drain while suspended which is caused also by not entering deep sleep mode.



    This issue is discussed on this thread on Lenovo's forum, in short the X1C6 opted to support Windows Modern Standby. If you read that thread carefully, you would see that although the symptom is shared, the root causes vary greatly between the XPS 13 9370 and the X1C6. e.g. The output of cat /sys/power/mem_sleep on the X1C6 would only be [s2idle] indicating missing support for deep sleep.



    The solutions posted so far for this question applies only to the XPS 13, and not to the X1C6. As far as I understand the best solution to the X1C6's suspend mode issue is to apply a DSDT patch first given by Delta Xi, and subsequently updated by PombeirP. This post takes you through how to apply the patch, but make sure you read the post and all of its updates before any actions.



    I wrote a gist documenting issues related to the installation of Ubuntu 18.04 on the Thinkpad X1 Carbon 6th Gen including solutions I found about the slow boot issue caused by LVM as well as this deep sleep issue.






    share|improve this answer





















      Your Answer








      StackExchange.ready(function() {
      var channelOptions = {
      tags: "".split(" "),
      id: "89"
      };
      initTagRenderer("".split(" "), "".split(" "), channelOptions);

      StackExchange.using("externalEditor", function() {
      // Have to fire editor after snippets, if snippets enabled
      if (StackExchange.settings.snippets.snippetsEnabled) {
      StackExchange.using("snippets", function() {
      createEditor();
      });
      }
      else {
      createEditor();
      }
      });

      function createEditor() {
      StackExchange.prepareEditor({
      heartbeatType: 'answer',
      convertImagesToLinks: true,
      noModals: true,
      showLowRepImageUploadWarning: true,
      reputationToPostImages: 10,
      bindNavPrevention: true,
      postfix: "",
      imageUploader: {
      brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
      contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
      allowUrls: true
      },
      onDemand: true,
      discardSelector: ".discard-answer"
      ,immediatelyShowMarkdownHelp:true
      });


      }
      });














       

      draft saved


      draft discarded


















      StackExchange.ready(
      function () {
      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1029474%2fubuntu-18-04-dell-xps13-9370-no-longer-suspends-on-lid-close%23new-answer', 'question_page');
      }
      );

      Post as a guest















      Required, but never shown

























      4 Answers
      4






      active

      oldest

      votes








      4 Answers
      4






      active

      oldest

      votes









      active

      oldest

      votes






      active

      oldest

      votes








      up vote
      37
      down vote



      accepted










      I think I managed to figure out what was going on, thanks to these two sources: Dell XPS 13 (9370) ArchLinux Install notes and Arch Linux Forum.



      For some reason, the laptop is not going in deep sleep anymore, but rather an s2idle mode which is merely a screen off type of suspend.



      Diagnosis of the issue



      To confirm whether this is the case for your system, suspend the laptop using your favorite method (close the lid, hit Fn+End, write pm-suspend in a terminal if you have pm-utils installed, or hit the Windows key type suspend and hit the Enter key).



      Wake up from suspend mode and type in a terminal: sudo journalctl | grep "PM: suspend" | tail -2.
      If the output is



      May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
      May 13 20:52:36 mex kernel: PM: suspend exit


      Then you are not entering deep sleep.
      You can also check cat /sys/power/mem_sleep which should return



      [s2idle] deep


      which confirms that the default suspend mode is s2idle (since it is highlighted with brackets).



      Temporary fix



      To try a temporary fix, do echo deep > /sys/power/mem_sleep as a root user. Check that it was successful by looking at the output of cat /sys/power/mem_sleep which should be



      s2idle [deep]


      then suspend the laptop and wake up again. If sudo journalctl | grep "PM: suspend" | tail -2 returns



      May 13 18:41:00 mex kernel: PM: suspend entry (deep)
      May 13 20:52:36 mex kernel: PM: suspend exit


      then the issue should be fixed.
      You can put your computer to sleep for a couple of hours and check whether the battery drain improved.



      Permanent fix



      To make it permanent, you have to edit your bootloader cmdline. To do so, edit as root user the file /etc/default/grub, by running for example sudo -H gedit /etc/default/grub. Replace the line



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


      with



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"


      and regenerate your grub configuration (run sudo grub-mkconfig -o /boot/grub/grub.cfg).






      share|improve this answer



















      • 1




        Alternative permanent fix, that doesn't involve changing kernel parameters: Install sysfsutils and echo 'power/mem_sleep = deep' > /etc/sysfs.d/mem_sleep.conf. sysfsutils is a tiny service that just restores sysfs parameters like this.
        – StrangeNoises
        May 17 at 11:30












      • This method certainly works, however it exposes another problem. It seems the bluetooth adapter isn't able to reliably wake up (it usually disappears for me after the second such sleep). This is a known problem described and possibly fixed here, where for the 9360 they've added a quirk to reset the adapter on resume. Looks like it'll be in 4.17. workaround btusb.enable_autosuspend=n only appears in 4.16 so we can't use that yet either. May have to install Fedora to join that conversation and confirm same fix for 9370 would work.
        – StrangeNoises
        May 18 at 16:58






      • 2




        I love this in depth answer, but in ubuntu 18 I'm getting issues at the echo deep step, wherein I'm getting an echo: write error: Invalid argument. This may be because i'm not in root properly. I can't su - because ubuntu has it disabled, so I tried both sudo -i and sudo su
        – Caleb Jay
        Jul 29 at 22:31






      • 1




        On Dell XPS 13 (9370), deep suspend mode doesn't work properly if disk encryption is enabled on Ubuntu 18.04. dell.com/community/XPS/…
        – Akihiro HARAI
        Aug 29 at 1:51






      • 1




        @CalebJay: Ubuntu spells su - as sudo -i. You can also change the root password with sudo passwd, if that's the way you prefer to administer your Unix boxes.
        – hackerb9
        Oct 22 at 4:19

















      up vote
      37
      down vote



      accepted










      I think I managed to figure out what was going on, thanks to these two sources: Dell XPS 13 (9370) ArchLinux Install notes and Arch Linux Forum.



      For some reason, the laptop is not going in deep sleep anymore, but rather an s2idle mode which is merely a screen off type of suspend.



      Diagnosis of the issue



      To confirm whether this is the case for your system, suspend the laptop using your favorite method (close the lid, hit Fn+End, write pm-suspend in a terminal if you have pm-utils installed, or hit the Windows key type suspend and hit the Enter key).



      Wake up from suspend mode and type in a terminal: sudo journalctl | grep "PM: suspend" | tail -2.
      If the output is



      May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
      May 13 20:52:36 mex kernel: PM: suspend exit


      Then you are not entering deep sleep.
      You can also check cat /sys/power/mem_sleep which should return



      [s2idle] deep


      which confirms that the default suspend mode is s2idle (since it is highlighted with brackets).



      Temporary fix



      To try a temporary fix, do echo deep > /sys/power/mem_sleep as a root user. Check that it was successful by looking at the output of cat /sys/power/mem_sleep which should be



      s2idle [deep]


      then suspend the laptop and wake up again. If sudo journalctl | grep "PM: suspend" | tail -2 returns



      May 13 18:41:00 mex kernel: PM: suspend entry (deep)
      May 13 20:52:36 mex kernel: PM: suspend exit


      then the issue should be fixed.
      You can put your computer to sleep for a couple of hours and check whether the battery drain improved.



      Permanent fix



      To make it permanent, you have to edit your bootloader cmdline. To do so, edit as root user the file /etc/default/grub, by running for example sudo -H gedit /etc/default/grub. Replace the line



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


      with



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"


      and regenerate your grub configuration (run sudo grub-mkconfig -o /boot/grub/grub.cfg).






      share|improve this answer



















      • 1




        Alternative permanent fix, that doesn't involve changing kernel parameters: Install sysfsutils and echo 'power/mem_sleep = deep' > /etc/sysfs.d/mem_sleep.conf. sysfsutils is a tiny service that just restores sysfs parameters like this.
        – StrangeNoises
        May 17 at 11:30












      • This method certainly works, however it exposes another problem. It seems the bluetooth adapter isn't able to reliably wake up (it usually disappears for me after the second such sleep). This is a known problem described and possibly fixed here, where for the 9360 they've added a quirk to reset the adapter on resume. Looks like it'll be in 4.17. workaround btusb.enable_autosuspend=n only appears in 4.16 so we can't use that yet either. May have to install Fedora to join that conversation and confirm same fix for 9370 would work.
        – StrangeNoises
        May 18 at 16:58






      • 2




        I love this in depth answer, but in ubuntu 18 I'm getting issues at the echo deep step, wherein I'm getting an echo: write error: Invalid argument. This may be because i'm not in root properly. I can't su - because ubuntu has it disabled, so I tried both sudo -i and sudo su
        – Caleb Jay
        Jul 29 at 22:31






      • 1




        On Dell XPS 13 (9370), deep suspend mode doesn't work properly if disk encryption is enabled on Ubuntu 18.04. dell.com/community/XPS/…
        – Akihiro HARAI
        Aug 29 at 1:51






      • 1




        @CalebJay: Ubuntu spells su - as sudo -i. You can also change the root password with sudo passwd, if that's the way you prefer to administer your Unix boxes.
        – hackerb9
        Oct 22 at 4:19















      up vote
      37
      down vote



      accepted







      up vote
      37
      down vote



      accepted






      I think I managed to figure out what was going on, thanks to these two sources: Dell XPS 13 (9370) ArchLinux Install notes and Arch Linux Forum.



      For some reason, the laptop is not going in deep sleep anymore, but rather an s2idle mode which is merely a screen off type of suspend.



      Diagnosis of the issue



      To confirm whether this is the case for your system, suspend the laptop using your favorite method (close the lid, hit Fn+End, write pm-suspend in a terminal if you have pm-utils installed, or hit the Windows key type suspend and hit the Enter key).



      Wake up from suspend mode and type in a terminal: sudo journalctl | grep "PM: suspend" | tail -2.
      If the output is



      May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
      May 13 20:52:36 mex kernel: PM: suspend exit


      Then you are not entering deep sleep.
      You can also check cat /sys/power/mem_sleep which should return



      [s2idle] deep


      which confirms that the default suspend mode is s2idle (since it is highlighted with brackets).



      Temporary fix



      To try a temporary fix, do echo deep > /sys/power/mem_sleep as a root user. Check that it was successful by looking at the output of cat /sys/power/mem_sleep which should be



      s2idle [deep]


      then suspend the laptop and wake up again. If sudo journalctl | grep "PM: suspend" | tail -2 returns



      May 13 18:41:00 mex kernel: PM: suspend entry (deep)
      May 13 20:52:36 mex kernel: PM: suspend exit


      then the issue should be fixed.
      You can put your computer to sleep for a couple of hours and check whether the battery drain improved.



      Permanent fix



      To make it permanent, you have to edit your bootloader cmdline. To do so, edit as root user the file /etc/default/grub, by running for example sudo -H gedit /etc/default/grub. Replace the line



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


      with



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"


      and regenerate your grub configuration (run sudo grub-mkconfig -o /boot/grub/grub.cfg).






      share|improve this answer














      I think I managed to figure out what was going on, thanks to these two sources: Dell XPS 13 (9370) ArchLinux Install notes and Arch Linux Forum.



      For some reason, the laptop is not going in deep sleep anymore, but rather an s2idle mode which is merely a screen off type of suspend.



      Diagnosis of the issue



      To confirm whether this is the case for your system, suspend the laptop using your favorite method (close the lid, hit Fn+End, write pm-suspend in a terminal if you have pm-utils installed, or hit the Windows key type suspend and hit the Enter key).



      Wake up from suspend mode and type in a terminal: sudo journalctl | grep "PM: suspend" | tail -2.
      If the output is



      May 13 18:41:00 mex kernel: PM: suspend entry (s2idle)
      May 13 20:52:36 mex kernel: PM: suspend exit


      Then you are not entering deep sleep.
      You can also check cat /sys/power/mem_sleep which should return



      [s2idle] deep


      which confirms that the default suspend mode is s2idle (since it is highlighted with brackets).



      Temporary fix



      To try a temporary fix, do echo deep > /sys/power/mem_sleep as a root user. Check that it was successful by looking at the output of cat /sys/power/mem_sleep which should be



      s2idle [deep]


      then suspend the laptop and wake up again. If sudo journalctl | grep "PM: suspend" | tail -2 returns



      May 13 18:41:00 mex kernel: PM: suspend entry (deep)
      May 13 20:52:36 mex kernel: PM: suspend exit


      then the issue should be fixed.
      You can put your computer to sleep for a couple of hours and check whether the battery drain improved.



      Permanent fix



      To make it permanent, you have to edit your bootloader cmdline. To do so, edit as root user the file /etc/default/grub, by running for example sudo -H gedit /etc/default/grub. Replace the line



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"


      with



      GRUB_CMDLINE_LINUX_DEFAULT="quiet splash mem_sleep_default=deep"


      and regenerate your grub configuration (run sudo grub-mkconfig -o /boot/grub/grub.cfg).







      share|improve this answer














      share|improve this answer



      share|improve this answer








      edited May 16 at 15:46









      Zanna

      48.9k13123234




      48.9k13123234










      answered May 14 at 13:40









      monty47

      53135




      53135








      • 1




        Alternative permanent fix, that doesn't involve changing kernel parameters: Install sysfsutils and echo 'power/mem_sleep = deep' > /etc/sysfs.d/mem_sleep.conf. sysfsutils is a tiny service that just restores sysfs parameters like this.
        – StrangeNoises
        May 17 at 11:30












      • This method certainly works, however it exposes another problem. It seems the bluetooth adapter isn't able to reliably wake up (it usually disappears for me after the second such sleep). This is a known problem described and possibly fixed here, where for the 9360 they've added a quirk to reset the adapter on resume. Looks like it'll be in 4.17. workaround btusb.enable_autosuspend=n only appears in 4.16 so we can't use that yet either. May have to install Fedora to join that conversation and confirm same fix for 9370 would work.
        – StrangeNoises
        May 18 at 16:58






      • 2




        I love this in depth answer, but in ubuntu 18 I'm getting issues at the echo deep step, wherein I'm getting an echo: write error: Invalid argument. This may be because i'm not in root properly. I can't su - because ubuntu has it disabled, so I tried both sudo -i and sudo su
        – Caleb Jay
        Jul 29 at 22:31






      • 1




        On Dell XPS 13 (9370), deep suspend mode doesn't work properly if disk encryption is enabled on Ubuntu 18.04. dell.com/community/XPS/…
        – Akihiro HARAI
        Aug 29 at 1:51






      • 1




        @CalebJay: Ubuntu spells su - as sudo -i. You can also change the root password with sudo passwd, if that's the way you prefer to administer your Unix boxes.
        – hackerb9
        Oct 22 at 4:19
















      • 1




        Alternative permanent fix, that doesn't involve changing kernel parameters: Install sysfsutils and echo 'power/mem_sleep = deep' > /etc/sysfs.d/mem_sleep.conf. sysfsutils is a tiny service that just restores sysfs parameters like this.
        – StrangeNoises
        May 17 at 11:30












      • This method certainly works, however it exposes another problem. It seems the bluetooth adapter isn't able to reliably wake up (it usually disappears for me after the second such sleep). This is a known problem described and possibly fixed here, where for the 9360 they've added a quirk to reset the adapter on resume. Looks like it'll be in 4.17. workaround btusb.enable_autosuspend=n only appears in 4.16 so we can't use that yet either. May have to install Fedora to join that conversation and confirm same fix for 9370 would work.
        – StrangeNoises
        May 18 at 16:58






      • 2




        I love this in depth answer, but in ubuntu 18 I'm getting issues at the echo deep step, wherein I'm getting an echo: write error: Invalid argument. This may be because i'm not in root properly. I can't su - because ubuntu has it disabled, so I tried both sudo -i and sudo su
        – Caleb Jay
        Jul 29 at 22:31






      • 1




        On Dell XPS 13 (9370), deep suspend mode doesn't work properly if disk encryption is enabled on Ubuntu 18.04. dell.com/community/XPS/…
        – Akihiro HARAI
        Aug 29 at 1:51






      • 1




        @CalebJay: Ubuntu spells su - as sudo -i. You can also change the root password with sudo passwd, if that's the way you prefer to administer your Unix boxes.
        – hackerb9
        Oct 22 at 4:19










      1




      1




      Alternative permanent fix, that doesn't involve changing kernel parameters: Install sysfsutils and echo 'power/mem_sleep = deep' > /etc/sysfs.d/mem_sleep.conf. sysfsutils is a tiny service that just restores sysfs parameters like this.
      – StrangeNoises
      May 17 at 11:30






      Alternative permanent fix, that doesn't involve changing kernel parameters: Install sysfsutils and echo 'power/mem_sleep = deep' > /etc/sysfs.d/mem_sleep.conf. sysfsutils is a tiny service that just restores sysfs parameters like this.
      – StrangeNoises
      May 17 at 11:30














      This method certainly works, however it exposes another problem. It seems the bluetooth adapter isn't able to reliably wake up (it usually disappears for me after the second such sleep). This is a known problem described and possibly fixed here, where for the 9360 they've added a quirk to reset the adapter on resume. Looks like it'll be in 4.17. workaround btusb.enable_autosuspend=n only appears in 4.16 so we can't use that yet either. May have to install Fedora to join that conversation and confirm same fix for 9370 would work.
      – StrangeNoises
      May 18 at 16:58




      This method certainly works, however it exposes another problem. It seems the bluetooth adapter isn't able to reliably wake up (it usually disappears for me after the second such sleep). This is a known problem described and possibly fixed here, where for the 9360 they've added a quirk to reset the adapter on resume. Looks like it'll be in 4.17. workaround btusb.enable_autosuspend=n only appears in 4.16 so we can't use that yet either. May have to install Fedora to join that conversation and confirm same fix for 9370 would work.
      – StrangeNoises
      May 18 at 16:58




      2




      2




      I love this in depth answer, but in ubuntu 18 I'm getting issues at the echo deep step, wherein I'm getting an echo: write error: Invalid argument. This may be because i'm not in root properly. I can't su - because ubuntu has it disabled, so I tried both sudo -i and sudo su
      – Caleb Jay
      Jul 29 at 22:31




      I love this in depth answer, but in ubuntu 18 I'm getting issues at the echo deep step, wherein I'm getting an echo: write error: Invalid argument. This may be because i'm not in root properly. I can't su - because ubuntu has it disabled, so I tried both sudo -i and sudo su
      – Caleb Jay
      Jul 29 at 22:31




      1




      1




      On Dell XPS 13 (9370), deep suspend mode doesn't work properly if disk encryption is enabled on Ubuntu 18.04. dell.com/community/XPS/…
      – Akihiro HARAI
      Aug 29 at 1:51




      On Dell XPS 13 (9370), deep suspend mode doesn't work properly if disk encryption is enabled on Ubuntu 18.04. dell.com/community/XPS/…
      – Akihiro HARAI
      Aug 29 at 1:51




      1




      1




      @CalebJay: Ubuntu spells su - as sudo -i. You can also change the root password with sudo passwd, if that's the way you prefer to administer your Unix boxes.
      – hackerb9
      Oct 22 at 4:19






      @CalebJay: Ubuntu spells su - as sudo -i. You can also change the root password with sudo passwd, if that's the way you prefer to administer your Unix boxes.
      – hackerb9
      Oct 22 at 4:19














      up vote
      8
      down vote













      Try creating /etc/systemd/sleep.conf:



      [Sleep]
      SuspendMode=
      SuspendState=mem


      And reboot. This seems to be working for me, although I'm not certain I didn't also get improvement with the /etc/systemd/logind.conf change I did first. In any case, no heat or fan noise is observed while suspended with the lid shut, and it doesn't respond to ping over wifi either, which I had been getting, intermittently, before.



      Battery life still goes down while suspended, probably because the working method of suspend is just less efficient than the default, ideal, method that apparently isn't working properly, but it appears better than the default behaviour.



      Tried on my XPS 13 9370, I don't know about older models, although it seems likely they'll be similar.



      I had tried installing pm-utils and using pm-suspend and that seemed to be suspending pretty effectively, so I wanted to see if I could make systemd-suspend do the same thing.



      I looked through the scripts in pm-utils to figure out what it was actually doing, and it looks like, in this situation, it was doing echo -n "mem" > /sys/power/state. So I created the /etc/systemd/sleep.conf file as shown above to match it.



      It's not entirely clear what the default behaviour is. The manpage for systemd-sleep.conf says that the distro should include /etc/systemd/sleep.conf with the compiled-in defaults commented out, so you can see this information, but in ubuntu this file is missing. I noticed though that if you cat /sys/power/state you get:



      freeze mem


      So I'm guessing that this is what it's doing by default. My guess is that freeze may be being accepted, in that it doesn't throw an error, which would otherwise cause systemd to move on to mem, but maybe doesn't actually work properly, or reliably, for complex reasons we seem unable to determine. So just sending mem instead is a hopeful stab at avoiding that and just doing what pm-suspend does.



      I suspect the SuspendMode setting is actually superfluous and doesn't do anything anyway. I suspect this because cat /sys/power/disk just gets you:



      [disabled]


      Am new user, thus unable to comment with an observation, forced to present it as an answer as if I'm super-confident in it! But I think it's working.






      share|improve this answer





















      • Before trying your changes my $ cat /sys/power/disk revealed: [platform] shutdown reboot suspend test_resume
        – WinEunuuchs2Unix
        May 14 at 2:54















      up vote
      8
      down vote













      Try creating /etc/systemd/sleep.conf:



      [Sleep]
      SuspendMode=
      SuspendState=mem


      And reboot. This seems to be working for me, although I'm not certain I didn't also get improvement with the /etc/systemd/logind.conf change I did first. In any case, no heat or fan noise is observed while suspended with the lid shut, and it doesn't respond to ping over wifi either, which I had been getting, intermittently, before.



      Battery life still goes down while suspended, probably because the working method of suspend is just less efficient than the default, ideal, method that apparently isn't working properly, but it appears better than the default behaviour.



      Tried on my XPS 13 9370, I don't know about older models, although it seems likely they'll be similar.



      I had tried installing pm-utils and using pm-suspend and that seemed to be suspending pretty effectively, so I wanted to see if I could make systemd-suspend do the same thing.



      I looked through the scripts in pm-utils to figure out what it was actually doing, and it looks like, in this situation, it was doing echo -n "mem" > /sys/power/state. So I created the /etc/systemd/sleep.conf file as shown above to match it.



      It's not entirely clear what the default behaviour is. The manpage for systemd-sleep.conf says that the distro should include /etc/systemd/sleep.conf with the compiled-in defaults commented out, so you can see this information, but in ubuntu this file is missing. I noticed though that if you cat /sys/power/state you get:



      freeze mem


      So I'm guessing that this is what it's doing by default. My guess is that freeze may be being accepted, in that it doesn't throw an error, which would otherwise cause systemd to move on to mem, but maybe doesn't actually work properly, or reliably, for complex reasons we seem unable to determine. So just sending mem instead is a hopeful stab at avoiding that and just doing what pm-suspend does.



      I suspect the SuspendMode setting is actually superfluous and doesn't do anything anyway. I suspect this because cat /sys/power/disk just gets you:



      [disabled]


      Am new user, thus unable to comment with an observation, forced to present it as an answer as if I'm super-confident in it! But I think it's working.






      share|improve this answer





















      • Before trying your changes my $ cat /sys/power/disk revealed: [platform] shutdown reboot suspend test_resume
        – WinEunuuchs2Unix
        May 14 at 2:54













      up vote
      8
      down vote










      up vote
      8
      down vote









      Try creating /etc/systemd/sleep.conf:



      [Sleep]
      SuspendMode=
      SuspendState=mem


      And reboot. This seems to be working for me, although I'm not certain I didn't also get improvement with the /etc/systemd/logind.conf change I did first. In any case, no heat or fan noise is observed while suspended with the lid shut, and it doesn't respond to ping over wifi either, which I had been getting, intermittently, before.



      Battery life still goes down while suspended, probably because the working method of suspend is just less efficient than the default, ideal, method that apparently isn't working properly, but it appears better than the default behaviour.



      Tried on my XPS 13 9370, I don't know about older models, although it seems likely they'll be similar.



      I had tried installing pm-utils and using pm-suspend and that seemed to be suspending pretty effectively, so I wanted to see if I could make systemd-suspend do the same thing.



      I looked through the scripts in pm-utils to figure out what it was actually doing, and it looks like, in this situation, it was doing echo -n "mem" > /sys/power/state. So I created the /etc/systemd/sleep.conf file as shown above to match it.



      It's not entirely clear what the default behaviour is. The manpage for systemd-sleep.conf says that the distro should include /etc/systemd/sleep.conf with the compiled-in defaults commented out, so you can see this information, but in ubuntu this file is missing. I noticed though that if you cat /sys/power/state you get:



      freeze mem


      So I'm guessing that this is what it's doing by default. My guess is that freeze may be being accepted, in that it doesn't throw an error, which would otherwise cause systemd to move on to mem, but maybe doesn't actually work properly, or reliably, for complex reasons we seem unable to determine. So just sending mem instead is a hopeful stab at avoiding that and just doing what pm-suspend does.



      I suspect the SuspendMode setting is actually superfluous and doesn't do anything anyway. I suspect this because cat /sys/power/disk just gets you:



      [disabled]


      Am new user, thus unable to comment with an observation, forced to present it as an answer as if I'm super-confident in it! But I think it's working.






      share|improve this answer












      Try creating /etc/systemd/sleep.conf:



      [Sleep]
      SuspendMode=
      SuspendState=mem


      And reboot. This seems to be working for me, although I'm not certain I didn't also get improvement with the /etc/systemd/logind.conf change I did first. In any case, no heat or fan noise is observed while suspended with the lid shut, and it doesn't respond to ping over wifi either, which I had been getting, intermittently, before.



      Battery life still goes down while suspended, probably because the working method of suspend is just less efficient than the default, ideal, method that apparently isn't working properly, but it appears better than the default behaviour.



      Tried on my XPS 13 9370, I don't know about older models, although it seems likely they'll be similar.



      I had tried installing pm-utils and using pm-suspend and that seemed to be suspending pretty effectively, so I wanted to see if I could make systemd-suspend do the same thing.



      I looked through the scripts in pm-utils to figure out what it was actually doing, and it looks like, in this situation, it was doing echo -n "mem" > /sys/power/state. So I created the /etc/systemd/sleep.conf file as shown above to match it.



      It's not entirely clear what the default behaviour is. The manpage for systemd-sleep.conf says that the distro should include /etc/systemd/sleep.conf with the compiled-in defaults commented out, so you can see this information, but in ubuntu this file is missing. I noticed though that if you cat /sys/power/state you get:



      freeze mem


      So I'm guessing that this is what it's doing by default. My guess is that freeze may be being accepted, in that it doesn't throw an error, which would otherwise cause systemd to move on to mem, but maybe doesn't actually work properly, or reliably, for complex reasons we seem unable to determine. So just sending mem instead is a hopeful stab at avoiding that and just doing what pm-suspend does.



      I suspect the SuspendMode setting is actually superfluous and doesn't do anything anyway. I suspect this because cat /sys/power/disk just gets you:



      [disabled]


      Am new user, thus unable to comment with an observation, forced to present it as an answer as if I'm super-confident in it! But I think it's working.







      share|improve this answer












      share|improve this answer



      share|improve this answer










      answered May 1 at 21:27









      StrangeNoises

      813




      813












      • Before trying your changes my $ cat /sys/power/disk revealed: [platform] shutdown reboot suspend test_resume
        – WinEunuuchs2Unix
        May 14 at 2:54


















      • Before trying your changes my $ cat /sys/power/disk revealed: [platform] shutdown reboot suspend test_resume
        – WinEunuuchs2Unix
        May 14 at 2:54
















      Before trying your changes my $ cat /sys/power/disk revealed: [platform] shutdown reboot suspend test_resume
      – WinEunuuchs2Unix
      May 14 at 2:54




      Before trying your changes my $ cat /sys/power/disk revealed: [platform] shutdown reboot suspend test_resume
      – WinEunuuchs2Unix
      May 14 at 2:54










      up vote
      3
      down vote













      The other answers here are excellent, in-depth and well researched.



      Unfortunately they didn't work for my particular machine :(



      If you have nVidia graphics, there seems to be a fix that is working for a good number of people, helpfully provided by cascagrossa in the answer to this question: Ubuntu 18.04 crashes on resuming from suspend



      It is suspected to be a buggy nouveau driver and can sort out suspend issues by adding nouveau.modeset=0 to grub and has been confirmed in the comments for helping fix the issue for others too.



      I've got Intel graphics on my problem machine and curiously I've had no suspend problems with Ubuntu or Kubuntu 18.04 on at least 3 other machines (my friend's and my own), so why this particular machine is being such a douche about it is unclear.



      I recommend anyone experiencing this sort of issue to follow these steps to help identify the problem:




      1. Do you have nVidia graphics? If so, try the nouveau.modeset=0 grub trick.



      2. Check that suspend works at all. If you are closing the lid and then opening it up later and it's not waking up, it may seem like it's failing to 'resume'.




        • You should be able to manually select suspend on any desktop but it's slightly hidden in Gnome Shell - you can either longpress the power button from the top right hand menu of the screen, or click that button whilst holding Alt or press the Super key and type in 'suspend'


        • By selecting suspend you can check that the screen has switched off, the power LED is flashing as it should and you'd expect that any fan running will also stop. If all this happens but then you can't get your machine to waken up then it would appear to be a 'resume' problem rather than a 'suspend' problem.


        • My issue has been that it's not actually going into suspend and Murray who asked the original question, when asked by collisionTwo to check this, realised the problem was arising when manually suspending too.


        • In my case (on the one problem laptop), the screen goes blank but the power LED stays on and if the fan is running it continues to run. The machine does not respond to any keypresses, touchpad movement or clicks or power button presses. The only thing that can be done is to shut it down.


        • I've tried playing music whilst going into suspend (to check that it's not just the screen going blank) but the music stops and the machine has basically seized up.





      3. Try your machine with a Live USB of 18.04 and check if you have similar suspend issues.




        • This will just confirm that the suspend issues are not to do with any additional programs that you have installed.


        • In my case I suspected it was because I had installed tlp which might have been interfering with the suspend mode somehow, but the same behaviour occurred with a Live USB of both Ubuntu 18.04 and Kubuntu 18.04





      4. Try out the other two well researched solutions provided here by monty47 and StrangeNoises and see if you get good results.




        • They seem to have helped a number of people get suspend back up and running properly on 18.04 and may be more to do with the machine going into an s2idle state rather than the sleep (deep) mode of a usual 'suspend'.




      5. If none of the solutions are working to resolve your suspend issues on 18.04 then try the accepted answer to this: Ubuntu 18.04 crashes on resuming from suspend




        • The provided solution by Matalak (who also asked the question) was to use UKUU to try an older 4.14 kernel.


        • My problem machine had no suspend issues with Ubuntu 17.10 and Kubuntu 17.10, so it makes sense since 17.10 uses the 4.14 kernel. It now suspends fine in both Ubuntu 18.04 and Kubuntu 18.04 using the 4.14 kernel.





      6. If you tried the other solutions and could only fix your suspend issues by going back to a 4.14 kernel, you might be interested in the bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950




        • It appears to only be affecting a few machines with a specific combination of hardware and can be difficult to identify in amongst other nouveau related problems or s2idle issues.


        • It seems to be more prevalent for those running a Bay Trail Atom Celeron/Pentium but others have reported a similar issue with other machines.


        • If you are able to check your kern.log after this failed suspend (i.e once you've had to shut down your machine and restart) you might notice it says PM: suspend entry (deep) and then you have no further entries apart from the many lines of booting up again.


        • There is currently a patch that seems to resolve the issue.


        • If you feel like adding your voice to the bug report, it would be interesting to see which particular machines are affected (and check that the patch fixes the issue for everyone).





      Also attempting to gather 'Suspend Issues in 18.04' together in this thread: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724






      share|improve this answer



























        up vote
        3
        down vote













        The other answers here are excellent, in-depth and well researched.



        Unfortunately they didn't work for my particular machine :(



        If you have nVidia graphics, there seems to be a fix that is working for a good number of people, helpfully provided by cascagrossa in the answer to this question: Ubuntu 18.04 crashes on resuming from suspend



        It is suspected to be a buggy nouveau driver and can sort out suspend issues by adding nouveau.modeset=0 to grub and has been confirmed in the comments for helping fix the issue for others too.



        I've got Intel graphics on my problem machine and curiously I've had no suspend problems with Ubuntu or Kubuntu 18.04 on at least 3 other machines (my friend's and my own), so why this particular machine is being such a douche about it is unclear.



        I recommend anyone experiencing this sort of issue to follow these steps to help identify the problem:




        1. Do you have nVidia graphics? If so, try the nouveau.modeset=0 grub trick.



        2. Check that suspend works at all. If you are closing the lid and then opening it up later and it's not waking up, it may seem like it's failing to 'resume'.




          • You should be able to manually select suspend on any desktop but it's slightly hidden in Gnome Shell - you can either longpress the power button from the top right hand menu of the screen, or click that button whilst holding Alt or press the Super key and type in 'suspend'


          • By selecting suspend you can check that the screen has switched off, the power LED is flashing as it should and you'd expect that any fan running will also stop. If all this happens but then you can't get your machine to waken up then it would appear to be a 'resume' problem rather than a 'suspend' problem.


          • My issue has been that it's not actually going into suspend and Murray who asked the original question, when asked by collisionTwo to check this, realised the problem was arising when manually suspending too.


          • In my case (on the one problem laptop), the screen goes blank but the power LED stays on and if the fan is running it continues to run. The machine does not respond to any keypresses, touchpad movement or clicks or power button presses. The only thing that can be done is to shut it down.


          • I've tried playing music whilst going into suspend (to check that it's not just the screen going blank) but the music stops and the machine has basically seized up.





        3. Try your machine with a Live USB of 18.04 and check if you have similar suspend issues.




          • This will just confirm that the suspend issues are not to do with any additional programs that you have installed.


          • In my case I suspected it was because I had installed tlp which might have been interfering with the suspend mode somehow, but the same behaviour occurred with a Live USB of both Ubuntu 18.04 and Kubuntu 18.04





        4. Try out the other two well researched solutions provided here by monty47 and StrangeNoises and see if you get good results.




          • They seem to have helped a number of people get suspend back up and running properly on 18.04 and may be more to do with the machine going into an s2idle state rather than the sleep (deep) mode of a usual 'suspend'.




        5. If none of the solutions are working to resolve your suspend issues on 18.04 then try the accepted answer to this: Ubuntu 18.04 crashes on resuming from suspend




          • The provided solution by Matalak (who also asked the question) was to use UKUU to try an older 4.14 kernel.


          • My problem machine had no suspend issues with Ubuntu 17.10 and Kubuntu 17.10, so it makes sense since 17.10 uses the 4.14 kernel. It now suspends fine in both Ubuntu 18.04 and Kubuntu 18.04 using the 4.14 kernel.





        6. If you tried the other solutions and could only fix your suspend issues by going back to a 4.14 kernel, you might be interested in the bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950




          • It appears to only be affecting a few machines with a specific combination of hardware and can be difficult to identify in amongst other nouveau related problems or s2idle issues.


          • It seems to be more prevalent for those running a Bay Trail Atom Celeron/Pentium but others have reported a similar issue with other machines.


          • If you are able to check your kern.log after this failed suspend (i.e once you've had to shut down your machine and restart) you might notice it says PM: suspend entry (deep) and then you have no further entries apart from the many lines of booting up again.


          • There is currently a patch that seems to resolve the issue.


          • If you feel like adding your voice to the bug report, it would be interesting to see which particular machines are affected (and check that the patch fixes the issue for everyone).





        Also attempting to gather 'Suspend Issues in 18.04' together in this thread: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724






        share|improve this answer

























          up vote
          3
          down vote










          up vote
          3
          down vote









          The other answers here are excellent, in-depth and well researched.



          Unfortunately they didn't work for my particular machine :(



          If you have nVidia graphics, there seems to be a fix that is working for a good number of people, helpfully provided by cascagrossa in the answer to this question: Ubuntu 18.04 crashes on resuming from suspend



          It is suspected to be a buggy nouveau driver and can sort out suspend issues by adding nouveau.modeset=0 to grub and has been confirmed in the comments for helping fix the issue for others too.



          I've got Intel graphics on my problem machine and curiously I've had no suspend problems with Ubuntu or Kubuntu 18.04 on at least 3 other machines (my friend's and my own), so why this particular machine is being such a douche about it is unclear.



          I recommend anyone experiencing this sort of issue to follow these steps to help identify the problem:




          1. Do you have nVidia graphics? If so, try the nouveau.modeset=0 grub trick.



          2. Check that suspend works at all. If you are closing the lid and then opening it up later and it's not waking up, it may seem like it's failing to 'resume'.




            • You should be able to manually select suspend on any desktop but it's slightly hidden in Gnome Shell - you can either longpress the power button from the top right hand menu of the screen, or click that button whilst holding Alt or press the Super key and type in 'suspend'


            • By selecting suspend you can check that the screen has switched off, the power LED is flashing as it should and you'd expect that any fan running will also stop. If all this happens but then you can't get your machine to waken up then it would appear to be a 'resume' problem rather than a 'suspend' problem.


            • My issue has been that it's not actually going into suspend and Murray who asked the original question, when asked by collisionTwo to check this, realised the problem was arising when manually suspending too.


            • In my case (on the one problem laptop), the screen goes blank but the power LED stays on and if the fan is running it continues to run. The machine does not respond to any keypresses, touchpad movement or clicks or power button presses. The only thing that can be done is to shut it down.


            • I've tried playing music whilst going into suspend (to check that it's not just the screen going blank) but the music stops and the machine has basically seized up.





          3. Try your machine with a Live USB of 18.04 and check if you have similar suspend issues.




            • This will just confirm that the suspend issues are not to do with any additional programs that you have installed.


            • In my case I suspected it was because I had installed tlp which might have been interfering with the suspend mode somehow, but the same behaviour occurred with a Live USB of both Ubuntu 18.04 and Kubuntu 18.04





          4. Try out the other two well researched solutions provided here by monty47 and StrangeNoises and see if you get good results.




            • They seem to have helped a number of people get suspend back up and running properly on 18.04 and may be more to do with the machine going into an s2idle state rather than the sleep (deep) mode of a usual 'suspend'.




          5. If none of the solutions are working to resolve your suspend issues on 18.04 then try the accepted answer to this: Ubuntu 18.04 crashes on resuming from suspend




            • The provided solution by Matalak (who also asked the question) was to use UKUU to try an older 4.14 kernel.


            • My problem machine had no suspend issues with Ubuntu 17.10 and Kubuntu 17.10, so it makes sense since 17.10 uses the 4.14 kernel. It now suspends fine in both Ubuntu 18.04 and Kubuntu 18.04 using the 4.14 kernel.





          6. If you tried the other solutions and could only fix your suspend issues by going back to a 4.14 kernel, you might be interested in the bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950




            • It appears to only be affecting a few machines with a specific combination of hardware and can be difficult to identify in amongst other nouveau related problems or s2idle issues.


            • It seems to be more prevalent for those running a Bay Trail Atom Celeron/Pentium but others have reported a similar issue with other machines.


            • If you are able to check your kern.log after this failed suspend (i.e once you've had to shut down your machine and restart) you might notice it says PM: suspend entry (deep) and then you have no further entries apart from the many lines of booting up again.


            • There is currently a patch that seems to resolve the issue.


            • If you feel like adding your voice to the bug report, it would be interesting to see which particular machines are affected (and check that the patch fixes the issue for everyone).





          Also attempting to gather 'Suspend Issues in 18.04' together in this thread: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724






          share|improve this answer














          The other answers here are excellent, in-depth and well researched.



          Unfortunately they didn't work for my particular machine :(



          If you have nVidia graphics, there seems to be a fix that is working for a good number of people, helpfully provided by cascagrossa in the answer to this question: Ubuntu 18.04 crashes on resuming from suspend



          It is suspected to be a buggy nouveau driver and can sort out suspend issues by adding nouveau.modeset=0 to grub and has been confirmed in the comments for helping fix the issue for others too.



          I've got Intel graphics on my problem machine and curiously I've had no suspend problems with Ubuntu or Kubuntu 18.04 on at least 3 other machines (my friend's and my own), so why this particular machine is being such a douche about it is unclear.



          I recommend anyone experiencing this sort of issue to follow these steps to help identify the problem:




          1. Do you have nVidia graphics? If so, try the nouveau.modeset=0 grub trick.



          2. Check that suspend works at all. If you are closing the lid and then opening it up later and it's not waking up, it may seem like it's failing to 'resume'.




            • You should be able to manually select suspend on any desktop but it's slightly hidden in Gnome Shell - you can either longpress the power button from the top right hand menu of the screen, or click that button whilst holding Alt or press the Super key and type in 'suspend'


            • By selecting suspend you can check that the screen has switched off, the power LED is flashing as it should and you'd expect that any fan running will also stop. If all this happens but then you can't get your machine to waken up then it would appear to be a 'resume' problem rather than a 'suspend' problem.


            • My issue has been that it's not actually going into suspend and Murray who asked the original question, when asked by collisionTwo to check this, realised the problem was arising when manually suspending too.


            • In my case (on the one problem laptop), the screen goes blank but the power LED stays on and if the fan is running it continues to run. The machine does not respond to any keypresses, touchpad movement or clicks or power button presses. The only thing that can be done is to shut it down.


            • I've tried playing music whilst going into suspend (to check that it's not just the screen going blank) but the music stops and the machine has basically seized up.





          3. Try your machine with a Live USB of 18.04 and check if you have similar suspend issues.




            • This will just confirm that the suspend issues are not to do with any additional programs that you have installed.


            • In my case I suspected it was because I had installed tlp which might have been interfering with the suspend mode somehow, but the same behaviour occurred with a Live USB of both Ubuntu 18.04 and Kubuntu 18.04





          4. Try out the other two well researched solutions provided here by monty47 and StrangeNoises and see if you get good results.




            • They seem to have helped a number of people get suspend back up and running properly on 18.04 and may be more to do with the machine going into an s2idle state rather than the sleep (deep) mode of a usual 'suspend'.




          5. If none of the solutions are working to resolve your suspend issues on 18.04 then try the accepted answer to this: Ubuntu 18.04 crashes on resuming from suspend




            • The provided solution by Matalak (who also asked the question) was to use UKUU to try an older 4.14 kernel.


            • My problem machine had no suspend issues with Ubuntu 17.10 and Kubuntu 17.10, so it makes sense since 17.10 uses the 4.14 kernel. It now suspends fine in both Ubuntu 18.04 and Kubuntu 18.04 using the 4.14 kernel.





          6. If you tried the other solutions and could only fix your suspend issues by going back to a 4.14 kernel, you might be interested in the bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1774950




            • It appears to only be affecting a few machines with a specific combination of hardware and can be difficult to identify in amongst other nouveau related problems or s2idle issues.


            • It seems to be more prevalent for those running a Bay Trail Atom Celeron/Pentium but others have reported a similar issue with other machines.


            • If you are able to check your kern.log after this failed suspend (i.e once you've had to shut down your machine and restart) you might notice it says PM: suspend entry (deep) and then you have no further entries apart from the many lines of booting up again.


            • There is currently a patch that seems to resolve the issue.


            • If you feel like adding your voice to the bug report, it would be interesting to see which particular machines are affected (and check that the patch fixes the issue for everyone).





          Also attempting to gather 'Suspend Issues in 18.04' together in this thread: https://ubuntuforums.org/showthread.php?t=2395562&p=13780724#post13780724







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Jul 3 at 18:02

























          answered Jun 6 at 19:28









          pHeLiOn

          510316




          510316






















              up vote
              1
              down vote













              Just want to add an answer to users of Thinkpad X1 Carbon 6th Gen which has a similar symptom i.e. battery drain while suspended which is caused also by not entering deep sleep mode.



              This issue is discussed on this thread on Lenovo's forum, in short the X1C6 opted to support Windows Modern Standby. If you read that thread carefully, you would see that although the symptom is shared, the root causes vary greatly between the XPS 13 9370 and the X1C6. e.g. The output of cat /sys/power/mem_sleep on the X1C6 would only be [s2idle] indicating missing support for deep sleep.



              The solutions posted so far for this question applies only to the XPS 13, and not to the X1C6. As far as I understand the best solution to the X1C6's suspend mode issue is to apply a DSDT patch first given by Delta Xi, and subsequently updated by PombeirP. This post takes you through how to apply the patch, but make sure you read the post and all of its updates before any actions.



              I wrote a gist documenting issues related to the installation of Ubuntu 18.04 on the Thinkpad X1 Carbon 6th Gen including solutions I found about the slow boot issue caused by LVM as well as this deep sleep issue.






              share|improve this answer

























                up vote
                1
                down vote













                Just want to add an answer to users of Thinkpad X1 Carbon 6th Gen which has a similar symptom i.e. battery drain while suspended which is caused also by not entering deep sleep mode.



                This issue is discussed on this thread on Lenovo's forum, in short the X1C6 opted to support Windows Modern Standby. If you read that thread carefully, you would see that although the symptom is shared, the root causes vary greatly between the XPS 13 9370 and the X1C6. e.g. The output of cat /sys/power/mem_sleep on the X1C6 would only be [s2idle] indicating missing support for deep sleep.



                The solutions posted so far for this question applies only to the XPS 13, and not to the X1C6. As far as I understand the best solution to the X1C6's suspend mode issue is to apply a DSDT patch first given by Delta Xi, and subsequently updated by PombeirP. This post takes you through how to apply the patch, but make sure you read the post and all of its updates before any actions.



                I wrote a gist documenting issues related to the installation of Ubuntu 18.04 on the Thinkpad X1 Carbon 6th Gen including solutions I found about the slow boot issue caused by LVM as well as this deep sleep issue.






                share|improve this answer























                  up vote
                  1
                  down vote










                  up vote
                  1
                  down vote









                  Just want to add an answer to users of Thinkpad X1 Carbon 6th Gen which has a similar symptom i.e. battery drain while suspended which is caused also by not entering deep sleep mode.



                  This issue is discussed on this thread on Lenovo's forum, in short the X1C6 opted to support Windows Modern Standby. If you read that thread carefully, you would see that although the symptom is shared, the root causes vary greatly between the XPS 13 9370 and the X1C6. e.g. The output of cat /sys/power/mem_sleep on the X1C6 would only be [s2idle] indicating missing support for deep sleep.



                  The solutions posted so far for this question applies only to the XPS 13, and not to the X1C6. As far as I understand the best solution to the X1C6's suspend mode issue is to apply a DSDT patch first given by Delta Xi, and subsequently updated by PombeirP. This post takes you through how to apply the patch, but make sure you read the post and all of its updates before any actions.



                  I wrote a gist documenting issues related to the installation of Ubuntu 18.04 on the Thinkpad X1 Carbon 6th Gen including solutions I found about the slow boot issue caused by LVM as well as this deep sleep issue.






                  share|improve this answer












                  Just want to add an answer to users of Thinkpad X1 Carbon 6th Gen which has a similar symptom i.e. battery drain while suspended which is caused also by not entering deep sleep mode.



                  This issue is discussed on this thread on Lenovo's forum, in short the X1C6 opted to support Windows Modern Standby. If you read that thread carefully, you would see that although the symptom is shared, the root causes vary greatly between the XPS 13 9370 and the X1C6. e.g. The output of cat /sys/power/mem_sleep on the X1C6 would only be [s2idle] indicating missing support for deep sleep.



                  The solutions posted so far for this question applies only to the XPS 13, and not to the X1C6. As far as I understand the best solution to the X1C6's suspend mode issue is to apply a DSDT patch first given by Delta Xi, and subsequently updated by PombeirP. This post takes you through how to apply the patch, but make sure you read the post and all of its updates before any actions.



                  I wrote a gist documenting issues related to the installation of Ubuntu 18.04 on the Thinkpad X1 Carbon 6th Gen including solutions I found about the slow boot issue caused by LVM as well as this deep sleep issue.







                  share|improve this answer












                  share|improve this answer



                  share|improve this answer










                  answered Aug 14 at 15:26









                  B.Gao

                  111




                  111






























                       

                      draft saved


                      draft discarded



















































                       


                      draft saved


                      draft discarded














                      StackExchange.ready(
                      function () {
                      StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1029474%2fubuntu-18-04-dell-xps13-9370-no-longer-suspends-on-lid-close%23new-answer', 'question_page');
                      }
                      );

                      Post as a guest















                      Required, but never shown





















































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown

































                      Required, but never shown














                      Required, but never shown












                      Required, but never shown







                      Required, but never shown







                      Popular posts from this blog

                      數位音樂下載

                      When can things happen in Etherscan, such as the picture below?

                      格利澤436b