It is Dell XPS 9500 laptop. I’ve noticed that my battery won’t last more than few days while suspended.
I found in the journal log that the default suspend state is s2idle and decided to experiment with ‘deep’ (S3 they say) suspend.
echo deep > /sys/power/mem_sleep
and suspended the system. The problem I hit is the machine never recovers from that state.
It powers on and just hangs showing the Dell’s logo. I’m not sure if this is meaningful info.
Can this be related to the nVidia card (and proprietary module) I have? Does it have anything to do with the LUKS encrypted root ? Is this S3 suspend mode even supposed to work ?
It seems to be similar to the issue described in this post.
Seems to be that laptop fails to recover from suspend, me and the other user who experienced the same problem were using open nvidia drivers, however you use proprietry drivers. Which leaves as to another common factor - DELL laptop(s).
Moreover, I have rested different distros and DEs, with the same result, however an ASUS laptop works properly with the same Distros/DEs.
As described in the linked post, I was doing some testing and it seems to be related how Dell handles laptop lid switch.
you may try the following:
- Suspend from menu, without closing the lid and attemtp to wake up by pressing the power button => this should work.
1.1 if you let laptop suspend without closing the lid and menu button, e.g. by the timer, it should also work.
close laptop lid and ket it suspend, afterwards, when you open the lid, it will light the power button, you can hear the fans, but the screen would not open, you need to do hard shut-down.
Play around with settings on how laptop lid toggle is handled, (e.g. set to ignore). I had mixed results here and will continue testing further.
I’m not sure about the lid switch. For the purpose of my tests I’m directly writing to /sys/power/state
echo mem > /sys/power/state
Which is exactly what systemd does on clicking on suspend.
I might test with all nvidia stuff blacklisted in kernel boot command line although I’m finding no failures in dmesg when testing STR as per https://www.kernel.org/doc/Documentation/power/basic-pm-debugging.txt
I was mentioning the lid switch, as at least in my experience, it behaves differently: it fails to boot if wake-up is triggered by opening laptop-lid.
With me it is even more generic - resume fails with the power button press. I’ll not even test lid open if that one is not working There could be some obscure ACPI boot option that can help. acpi=off is not a (permanent) solution as I want power off initiated from the OS to work too but I might test just to rule this out… or not.
A post was split to a new topic: Battery drained while suspended