28

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.

  • 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 '11 at 19:28
  • Yeah no luck. Apparently there's no method to debugging suspend, which is a bit shocking. – mlissner Feb 4 '11 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 '11 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. – David Foerster Jun 29 '18 at 10:20
  • 2
    @pbhj: Either way one needs a proper issue diagnosis as the first step on the path towards a solution. – David Foerster Jul 1 '18 at 21:50
22
+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
    How do I turn off restricted devices? – Owen Feb 29 '16 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 ... – Scott Stensland Jun 5 '17 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.

  • 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 '11 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 '11 at 0:05
  • Thanks: Sometimes it is useful to read the original homepage! – abu_bua Jul 1 '18 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
  • Looks good! I'll wait another day or two to give others a chance to answer. Maybe somebody will feel inspired by yours. :-) – David Foerster Jun 29 '18 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. – WinEunuuchs2Unix Jun 29 '18 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. – David Foerster Jun 29 '18 at 10:19
  • @DavidFoerster In that case I'll let the answer stand as is :) – WinEunuuchs2Unix Jun 29 '18 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.