How many times have I moved your random ramblings to new Support threads now? C’mon… 
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? 
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. 
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.
So, you bundled a whole heap of maybe-fixes, rebooted, and the issue disappeared; and you’re left scratching your head in confusion, because you don’t know which fix actually worked. Does that sum it up?
I think you might have the scientific method slightly back asswards.
1 Like
Yeah since I need this machine to get my work done I rolled back my “best working” state and settings and installed 6.6rc6 update in parallel, and discovered that the issue is gone.
PS: I prefer scientific way too, it just would have taken a lot of time, so no tinkering for a while 
PPS: nice, sleep/resume under 6.1 also works in optimus-manager Hybrid mode, I’m one step closer to the conclusion that disabling Nvidia was the culprit.
1 Like
Oh, I didn’t know that. Are those powerprofiles as extensive as in tlp? Maybe tlp is adding some confusion? Where do I find those powerprofiles? All I see are the usual energy saving options which existed since the very early days of Plasma 5 and don’t decide about the hardware behavior during suspend/hibernation/shut down, only when they happen, so those never looked like any replacement for tlp.
EDIT: I found some info:
Still, it says about balance energy use against performance, while tlp does that too, but much more.
It is unclear what each setting does. Is there any more detailed info somewhere?
So, my conclusion based on a couple of weeks long observations and experiments is something around 6.1 (or backported from 6.2, 6.3, etc) regarding suspending procedure had changed that started to affect the way unmanaged (no Nvidia driver, device removed) Nvidia chip suspend in a manner that it prevents system from resuming. Nouveau is not an alternative, with it I see the same results.
So I have to use 5.15 without Nvidia driver or 6.1 or newer kernel with Optimus hybrid setup.
Seems going OT to try and explain everything about power-profiles-daemon etc … but heres a wiki link with more links: CPU frequency scaling - ArchWiki
1 Like
Turns out it was a hardware failure: my battery was the reason (kinda worn out, kinda – because 88% of original capacity doesn’t sound like worn out, right?). After replacing it resuming from suspend works flawlessly.
It’s interesting though that with 5.15 it worked fine for a while, then started to fail [in this regard] too, and Windows / macOS were totally fine with such battery, so it feels like Linux is quite picky on this.
UPD: it IS very picky, it started to behave this way again. Feels like I have to say farewell to Linux on this machine…
2 Likes