My laptop often fails to resume from sleep -- no reaction on pressing keyboard keys

I’m going to highlight a longstanding problem not related to this update specifically but this issue is not easy to track, because sometimes it occurs and sometimes it doesn’t. That’s why I’d better describe it anyway just in case.

My laptop often fails to resume from sleep when running any kernel between 6.1 and 6.6 especially with Google Chrome opened. 5.15 unaffected: I suspend it from time to time for about a week now and so far there was no failure to resume on 5.15. Chrome is not the only suspect because it happened a couple of times on Ubuntu (dev 23.10 with Linux 6.2, Intel-only mode) when running no apps at all, it just blanked to suspend and didn’t wake up. I’m going to try to enable nvidia-suspend and resume services but I’m not sure it would be of help. Most likely (I’m inclined to think this way for some reason) this is Nvidia GPU thing even if it is powered off.

With no information about things like … what kind of laptop it is … it will be very difficult to help.

You arent new. include an inxi or something.

1 Like

Do you actually need it to sleep?
Allowing a ‘suspend’ state instead could be a viable workaround.

Probably worth trying; no idea how effective it might be though. Cheers.

1 Like

This wasn’t supposed to be a support thread, I had posted in Unstable updates section but @Yochanan split it for some reason. All I wanted was to share my experience and observations. I clearly understand no one can help me on the stage I am being at now (trying to figure what the heck is going on).

I don’t have a laptop. I only use a desktop, which I suspend during the evenings. (Because it’s faster to resume from suspend in the morning than to cold-boot.)

With anything greater than Kernel 6.1 LTS, resume fails. Both 5.15 and 6.1 works fine. I read somewhere (Stackoverflow, probably) about someone having trouble with suspend and non-LTS kernels, so I figured I’d use this one and wait for, and check the next LTS version.


My nvidia* services below:

$systemctl status nvidia-hibernate.service nvidia-persistenced.service nvidia-powerd.service nvidia-resume.service nvidia-suspend.service nvidia-suspend.service                                                                                     1 ↵
○ nvidia-hibernate.service - NVIDIA system hibernate actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-hibernate.service; disabled; preset: disabled)
Active: inactive (dead)

○ nvidia-persistenced.service - NVIDIA Persistence Daemon
Loaded: loaded (/usr/lib/systemd/system/nvidia-persistenced.service; disabled; preset: disabled)
Active: inactive (dead)

○ nvidia-powerd.service - nvidia-powerd service
Loaded: loaded (/usr/lib/systemd/system/nvidia-powerd.service; disabled; preset: disabled)
Active: inactive (dead)

○ nvidia-resume.service - NVIDIA system resume actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-resume.service; disabled; preset: disabled)
Active: inactive (dead)

○ nvidia-suspend.service - NVIDIA system suspend actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-suspend.service; enabled; preset: disabled)
Active: inactive (dead)

Oct 13 17:38:41 Mirdarthos-PC systemd[1]: Starting NVIDIA system suspend actions...
Oct 13 17:38:41 Mirdarthos-PC suspend[51861]: nvidia-suspend.service
Oct 13 17:38:41 Mirdarthos-PC logger[51861]: <13>Oct 13 17:38:41 suspend: nvidia-suspend.service
Oct 13 17:38:42 Mirdarthos-PC systemd[1]: nvidia-suspend.service: Deactivated successfully.
Oct 13 17:38:42 Mirdarthos-PC systemd[1]: Finished NVIDIA system suspend actions.

○ nvidia-suspend.service - NVIDIA system suspend actions
Loaded: loaded (/usr/lib/systemd/system/nvidia-suspend.service; enabled; preset: disabled)
Active: inactive (dead)

Oct 13 17:38:41 Mirdarthos-PC systemd[1]: Starting NVIDIA system suspend actions...
Oct 13 17:38:41 Mirdarthos-PC suspend[51861]: nvidia-suspend.service
Oct 13 17:38:41 Mirdarthos-PC logger[51861]: <13>Oct 13 17:38:41 suspend: nvidia-suspend.service
Oct 13 17:38:42 Mirdarthos-PC systemd[1]: nvidia-suspend.service: Deactivated successfully.
Oct 13 17:38:42 Mirdarthos-PC systemd[1]: Finished NVIDIA system suspend actions.

I also struggled with graphics corruption on resume, causing me to have to restaart kwin on resume every time, to fix it. Well, this article had the fix for that. My /etc/modprobe.d/nvidia-power-management.conf:

$ cat /etc/modprobe.d/nvidia-power-management.conf                                                                                                                                                                                                 

options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/var/tmp

But other than that,

:man_shrugging:

1 Like

Thank you all for your suggestions, I decided to ditch nvidia driver at all, the dedicated MX150 I have on board is too hilariously weak for anything serious anyway, especially considering power draw and heat it generates. So I am going to use nouveau as it lately got much better at handling chips like MXxxx and GTX1xxx, and since my HDMI and USB Type C connectors are not wired to Nvidia chip I won’t lose any critical features I might need.
Now putting this machine to suspend-then-hibernate and will see how it behaves tomorrow morning.

PS:

This is likely a lost in translation case, my apologies. In Russian we sometimes say “sleep” referring to a computer’s suspend mode.

1 Like

How many times have I moved your random ramblings to new Support threads now? C’mon… :stuck_out_tongue_winking_eye:

Yeah I mean I thought that my description of the issue was too vague to seek any help at the time, and it had been for so long that I literally felt that I have to post it somewhere anyway just to I don’t know… find somebody with similar story saying I am not getting mad and my observations are indeed correct.

So, [as expected,] I had no much luck resolving this issue with switching over to nouveau. Even disabling Nvidia chip at all didn’t make any difference with regard to failures to resume. I keep thinking this is somehow related to kernel as all occurrences of such behavior happened on kernel 6.5 or 6.6, 5.15 is unaffected at all. What I didn’t tried this time though is closing/opening lid (only pressed kbd buttons – including power button – in order to wake the machine), but I tried that before today’s experiments with no result too. What’s interesting is that this happens almost every time I just boot Manjaro and do not enter my password, leave it on SDDM screen and wait till laptop goes to sleep. And almost never when I manually put it to sleep with systemctl command or using GUI tools.

Logs are clear, no trace of any error during suspending.
See how bizarre it is? This is why I didn’t want to start a new thread because I have no idea how could I get any more info on this.

Are the wake-on-mouse or similar options configured in BIOS? :person_shrugging:

Well, I’m from South Africa, and to me sleep mode is synonymous to suspend…if it’s not, someone is welcome to inform me, but I did check again (can’t remember where, just now.)

1 Like

Well, both are correct, though sometimes referred to by different names: Sleep (aka Hibernation) and Suspend (aka Standby) are both two separate Power Saving states.

Here is a mini writeup (meant for another thread) for your amusement:

With Hibernation (Sleep), your work is saved to a hibernation file and the computer switches off: If set correctly in BIOS, it can be woken (read: switched on) again by moving the mouse, or touching a keyboard button.

With Standby (Suspend), your work is saved to memory. Leaving the Standby (Suspend) state is faster than leaving the Hibernation (Sleep) state. If Standby (Suspend) is in effect for an extended period, then the computer state switches to Hibernation (Sleep) mode.

These modes can be regulated usually by changing the duration of each state in whatever Power Settings are available in your OS.

1 Like

My BIOS settings are very limited. All I have there is Wake on keyboard (enabled), Wake on lid (enabled), USB power on S3 (any other option disables wake on keyboard), and that’s basically it, the rest is unrelated to suspend mode. And yes, I meant suspend when I talked about “sleep”, by default it is S3 (to RAM), I modded it to s2idle (freeze), which shows a similar behaviour – no resume from time to time – no difference with the default platform setting; as for hibernation, it works and suspend-then-hibernate action and subsequent waking up also works fine. I’ve been experimenting with 5.15 a lot today, and its suspend/resume functions properly in 100% of my tests. Now I installed 6.1 just to check it once again.

I hope 6.1 solves it; especially considering its supposed to be the minimum recommended kernel, currently. I’m starting to see a few random comments that latest 6.6 iterations are solving a few issues; I don’t recall which though. This at least seems promising.

I have the same problem that shows up and disappears from time to time.

I’m using an old Alienware laptop for over 8 years. At the beginning there were serious problems with suspending, so I avoided that. Then, all were fixed just like that. I did nothing, just updated the system. For a few years it worked like a charm and it was a relief! I could finally close lid and then open it to resume the work. Then kernels 6 came up, and the issue appeared again, but this time randomly. Sometimes suspend works, sometimes it bugs the whole session and I need to force restart it.

I recently updated my tlp config (from pacnew and changed some settings) to see if it helped and so far, and the last few suspends were OK, which was surprising, because lately the rate of failed ones was like 9 bugged out to 1 without issues.
I need more testing and probably more revisions of tlp config, because there are so many options there that I don’t understand and which may fix the issue.

1 Like

Thanks for sharing, my experience is quite similar, and my laptop is maybe a bit newer than yours, it is a Xiaomi Notebook Pro made in 2017, Intel Kaby Lake i7 8550u. The first kernel version that worked without issues on it was 5.10, 5.15 is even better and it is in fact more than enough for me but still I’d want to get updated drivers stack because why not. :upside_down_face:

I haven’t used tlp since the release of powerprofile support in Plasma which conflicts with the former, and now that you’ve mentioned it I guess I could name another possible culprit, and that’s usb drivers, so if you are going to experiment with tlp you could start with usb options.

Yeah, once you tried and got used to suspend/resume, it is hard to live without it, that’s why 5.15 will be a choice of mine for the next few months I guess.

The Arch wiki says otherwise.

Suspend to RAM (aka suspend, aka sleep)
Suspend to disk (aka hibernate)

https://wiki.archlinux.org/title/Power_management/Suspend_and_hibernate

Sleep shuts off power to most of the machine but keeps the memory powered. Hibernation saves the contents of memory to swap and powers down everything.

Hybrid sleep first saves the contents of memory to swap, then sleeps. So if the computer loses power it can still resume from hibernation.

3 Likes

Agreed. Most commonly ‘sleep’ refers to suspend (to RAM).

2 Likes

Perhaps the ArchWiki is wrong.

Terminology aside, the point is that there are two distinct states (actually more, but two for simplicity) that most people treat as being the same; and they throw everything under the one banner, calling it sleep.

You can easily meander through life thinking “who cares”, until the difference actually matters; as was the case for a Poster in the thread I wrote this for. They didn’t understand why a USB speaker didn’t work when the computer was asleep; or the explanations given by several people.

It simply made no sense because, despite anything they were told, the computer was ‘asleep’, and nothing else entered into the equation; it’s 2-dimensional thinking. If they can’t understand something, it’s not true.

There comes a time when you have to ask; at least in the privacy of your own thoughts; “Seriously? How can you not understanding this?”

:end mini-rant

The issue hasn’t manifested itself since the update to 6.6-rc6. Honestly I don’t even want to try 6.1 now as 6.6 works very well already. But no idea what made it to stop occurring, maybe some other actions like reverting my Optimus manager setup to boot in auto hybrid mode. Will see when I have more time to experiment.