Unreliable suspend / resume with A05 and A06 bios (UPDATED)
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.
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.
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.
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:
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.
The A05 bios is shipped with the revised motherboards which suffered from the coil whine issue. AFAIK it's still `beta' so the only way you end up with it is with a brand new machine, or a motherboard swap.
The issue is independent of X and can be triggered in init 3 state directly with pm-suspend. It also seems to be some what random and only occurs after the system has been turned on, and plugged in, then unplugged and suspended.
I wonder why it can't be downloaded from the support page, there's only the A04 revision there.
I did disable screen blanking, and suspend after inactivity. only using it manually or when lid is closed
I'm sorry, but I didn't understand what you mean exactly. In any case, are you sure the laptop is not really working on resume? (can you ping it? Is the keyboard backlight changing level through the Fn keys? etc...)
ppeemm
13 Posts
1166
0
Posted November 14th, 2014 02:00
Same here.
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.