I've been chasing a suspend resume problem for a while. In general suspend / resume from and to memory works reasonably well. However I've found that after the system has been in an idle state for a while, screen off, system unused, and plugged in (but online), when closing the lid, and unplugging it, which initiates pm-suspend to memory.
That said, suspend to memory only seems to fail after long periods of idle, and of that, it seems some what random.
Debugging this, pm-suspend indicates that suspend to memory request takes place, however at that point (in which the BIOS should take over) the system hard locks and requires power cycling.
I've had this problem before on other dells and eventually, in all cases it required a BIOS fix. Would someone at Dell please investigate this?
My system freezes sometimes upon suspend (i.e. refuses to suspend, or to go back to a normal state), I have to power it off and reboot.
It is fairly random, but happens more with systemd than with pm-suspend, and I don't remember having seen it in "flight mode" (using the "F2/poweroff" key).
I'm using debian testing, with no power manager other than acpid and pm-tools.
One thing to make sure of is that Intel RapidStart and QuickConnect technologies are disabled.
In my case, I notice this tends to happen more reliably if the power is connected, then removed, then the system put to sleep.
So I've noticed that a reliable reproducer is to allow the system to idle for a while on AC power, then try and sleep, it doesn't seem to matter whether or not you unplug the AC.
I've been testing different settings for a couple of days, that appear to solve this issue:
- enabled rapidstart and smartconnect in the BIOS (the problem seemed somehow linked with the wifi board, hence smartconnect, and with suspend, hence rapidstart).
- added intel-rst and intel-smartconnect to /etc/modules.
My computer now seems to suspend well every time, and wakes up as expected.
Please confirm on your system.
This doesn't appear to make much difference on my laptop. It still hangs randomly when handing over to the bios.
Thanks for the suggestion though.
Indeed, it just reduced the frequency of it in my case, but the bug was still there.
However, your "reliable reproducer" from an earlier post disappeared when I disabled the power saving features in the acpi script that handles lid close.
There are indications there: [View:xps13-9333.appspot.com/:550:0]
Are you talking about the XPS13 9333? If so, where did you get the A05 revision? AFAIK A04 is the last one.
Anyway, does this problem happen only after the screen was turned off because of inactivity? If so, I'm wondering if the bug fixed by this commit has anything to do with it.
Basically it's just the screen that stays off.
To find out if that's the problem, you can do a simple test. Try to assign a keyboard shortcut so that the following command is executed:
echo 0 > /sys/class/backlight/intel_backlight/bl_power
Note that root permissions are required. So either you make sure that when you press the keyboard shortcut the command is run as root or change the permissions of that file (to 666, just for testing purposes).
Try to trigger the bug (reduce the interval after which the screen is turned off and suspended) and see if you can turn the screen on with that shortcut once the laptop is resumed.
Xps 13 9333 A05 Ubuntu 14.10.
I did disable screen blanking, and suspend after inactivity. only using it manually or when lid is closed