30

I've been using Ubuntu for about five years now, and I still can't make it suspend when I want to. It's quite irritating that I can program up a storm, hack the machine in numerous other ways, and yet, and yet when I try to make it suspend or debug suspend, I fail miserably.

I need help.

Where do I begin to find the problem? What do I do to fix it? I'm placing a bounty on this, because I've literally lost hours of my life to this problem, and leaving my computer on ALL the time is terrible.

The symptoms:

  • Pressing suspend brings my computer to a state where it has a blinking cursor, the fans are running, it seems that the HD has turned off (I think), and I can't do anything to bring it back from this state (short of a hard reboot).
  • Possibly related: My fans stay on even after a shutdown, and even then, I have to press the power button for five seconds before I can start it up again.
  • I don't know what logs to look at to debug the problem, and I imagine they'd get nuked on reboot anyway.

Please, please help. This drives me completely nuts, and I've been living with it for over a year.

7
  • Have you had any luck with this? I'm personally stuck initializing the graphics hardware. I could probably program my way out of it given enough time... but it would be much smoother to have some method for getting to the problem directly.
    – Henrik
    Jan 31, 2011 at 19:28
  • Yeah no luck. Apparently there's no method to debugging suspend, which is a bit shocking.
    – mlissner
    Feb 4, 2011 at 6:00
  • 1
    How are you suspending? Are you running, from the command line pm-suspend? Are you using a suspend key on your keyboard? Are you making a call to acpi (e.g. /etc/acpi/sleep.sh or /etc/acpi/sleepbtn.sh)??
    – M. Tibbits
    Feb 4, 2011 at 15:58
  • 1
    To bounty hunters: I'm looking mostly for general debugging recipes, i. e. information gathering, for more recent Ubuntu installations using systemd. My hope is that we can use this question as a canonical duplicate for broad suspend problem questions by inexperienced users. Jun 29, 2018 at 10:20
  • 2
    @pbhj: Either way one needs a proper issue diagnosis as the first step on the path towards a solution. Jul 1, 2018 at 21:50

3 Answers 3

23
+25

From https://wiki.ubuntu.com/UnderstandingSuspend

  • Biggest problem is graphics hardware
  • try suspend without restricted devices (nvidia, fglrx)
  • kernel doesn't know how to handle graphical devices
  • BIOS knows how to restore graphics state
    • via 16 bit segmented mode, C000:xxxx contains the visible 64k video ROM.
    • starting execution at C000:0003, normally re-POSTs the video BIOS (/usr/sbin/vbetool post)
      • more difficult in 64bit mode, since 16bit calls need to be emulated.
      • some memory is in 3-4G range, which requires remapping when emulating to avoid hitting the kernel which is mapped in the same space. o video BIOS may have paged POST code out of C000 window o nvidia BIOS rewrites ROM to just return to stop re-POSTing try suspend from console (via /etc/acpi/sleep.sh)
    • make sure you're logged out of Xorg (or run sleep.sh with "force" argument)
    • if the video BIOS isn't left in a sane state, returning to Xorg may hang the hardware
    • tests capslock on resume (if no capslock, kernel hung)
    • if backlight doesn't come back on, video BIOS probably didn't reinitialize
    • if screen is blank, but has a backlight, try hitting enter or switching between virtual terminals
    • try in single-user mode (via appending "single" to the grub kernel boot options)
    • for details on actions, try bash -x /etc/acpi/sleep.sh >/root/sleep.log 2>&1
    • look at dmidecode information that matches settings in /usr/share/acpi-support/*.config
    • if single-user mode console suspend or resume fails
    • PM trace (echo "1" > /sys/power/pm_trace) which will write device hashes to the system timer
    • attempt to suspend
    • after the failure, on reboot, examine the dmesg output for "device hash" entries to track down the device that hung the system during resume.
    • aware that this will reset the system clock, and fsck will freak out ("has gone without a fsck for 31337 days"). consider tune2fs -c 0 /dev/your/filesystems.
2
  • 2
    How do I turn off restricted devices?
    – Owen
    Feb 29, 2016 at 2:42
  • 1
    any links to working scripts to sanity check a box when suspend fails ? ... this kind of issue is the bane of linux and blocks mass usage ... Jun 5, 2017 at 4:04
4

You can find a lot of guidelines/advices here and here.

From your description, it sounds as if your ACPI is not working properly, or the kernel drivers are preventing a full suspend. The second link shows how to deal with that kind of problem.

3
  • 2
    I read these over, but they stop short of actually useful information for my problem. Need more help, and better particulars. I've created a bounty for this question.
    – mlissner
    Jan 29, 2011 at 23:33
  • 4
    Bad answer - just links. The point of the Stack*-sites is to provide a go-to place for all questions, not to send users on an endless goose-chase or say 'just f* google it'. Please insert your answer into the question and update it according to mlissner's comment.
    – Henrik
    Jan 30, 2011 at 0:05
  • Thanks: Sometimes it is useful to read the original homepage!
    – abu_bua
    Jul 1, 2018 at 14:42
4
+250

The symptoms:

  • Pressing suspend brings my computer to a state where it has a blinking cursor, the fans are running, it seems that the HD has turned off (I think), and I can't do anything to bring it back from this state (short of a hard reboot).
  • Possibly related: My fans stay on even after a shutdown, and even then, I have to press the power button for five seconds before I can start it up again.
  • I don't know what logs to look at to debug the problem, and I imagine they'd get nuked on reboot anyway.

My go to site for many Linux problems is Arch Linux. Here is what is posted about suspend/resume problems similar to yours:

Instantaneous wakeups from suspend

For some Intel Haswell systems with the LynxPoint and LynxPoint-LP chipset, instantaneous wakeups after suspend are reported. They are linked to erroneous BIOS ACPI implementations and how the xhci_hcd module interprets it during boot. As a work-around reported affected systems are added to a blacklist (named XHCI_SPURIOUS_WAKEUP) by the kernel case-by-case.[2]

Instantaneous resume may happen, for example, if a USB device is plugged during suspend and ACPI wakeup triggers are enabled. A viable work-around for such a system, if it is not on the blacklist yet, is to disable the wakeup triggers. An example to disable wakeup through USB is described as follows.[3]

To view the current configuration:

$ cat /proc/acpi/wakeup

Device  S-state   Status   Sysfs node
...
EHC1      S3    *enabled  pci:0000:00:1d.0
EHC2      S3    *enabled  pci:0000:00:1a.0
XHC       S3    *enabled  pci:0000:00:14.0

...

The relevant devices are EHC1, EHC2 and XHC (for USB 3.0). To toggle their state you have to echo the device name to the file as root.

# echo EHC1 > /proc/acpi/wakeup
# echo EHC2 > /proc/acpi/wakeup
# echo XHC > /proc/acpi/wakeup

This should result in suspension working again. However, this settings are only temporary and would have to be set at every reboot. To automate this take a look at systemd#Writing unit files. See BBS thread for a possible solution and more information.


The entire Arch Linux article above on Suspend/Resume is a great reference for many areas:

1 Low level interfaces
    1.1 kernel (swsusp)
    1.2 uswsusp
2 High level interfaces
    2.1 systemd
3 Hibernation
    3.1 About swap partition/file size
    3.2 Required kernel parameters
        3.2.1 Hibernation into swap file
    3.3 Configure the initramfs
4 Troubleshooting
    4.1 ACPI_OS_NAME
    4.2 VAIO Users
    4.3 Suspend/hibernate doesn't work, or not consistently
    4.4 Wake-on-LAN
    4.5 Instantaneous wakeups from suspend
4
  • Looks good! I'll wait another day or two to give others a chance to answer. Maybe somebody will feel inspired by yours. :-) Jun 29, 2018 at 9:59
  • @DavidFoerster Thanks. It's challenging to answer an 8 year old question. There is also a suspend/resume problem with NVMe M.2 PCIe SSD's I will be adding tonight. These types of SSD's didn't exist in 2010 and require a special grub kernel argument. Jun 29, 2018 at 10:15
  • I was looking less for solutions to specific suspend issues and more for general debugging recipes for more recent Ubuntu installations using systemd. Jun 29, 2018 at 10:19
  • @DavidFoerster In that case I'll let the answer stand as is :) Jun 29, 2018 at 10:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .