Seeing what free -h gives would be useful (wonder if the OP didn’t see post 13).
I’d suggest at least 1.5X RAM, more perhaps for low-RAM systems.
total used free shared buff/cache available
Mem: 7.6Gi 6.3Gi 657Mi 1.6Gi 2.5Gi 1.3Gi
Swap: 9Gi 3.5Gi 6.5Gi
I didn’t realise it would give more info than inxi
1 Like
Aha! Now I see that you are well into swap. It does look like you need to add more RAM if it’s possible on your board. There definitely isn’t room for “Hibernate” to work, although I’d still expect “Suspend” to be OK.
What’s your current uptime by the way?
Never more than 12h (and currently 4h)
Always worth checking that as, if for example, you’ve been using e.g. Firefox to watch YouTube videos, this will cause swap usage to go up over time. In your case, I doubt that is the main issue. 
I did more tests with the numbers in free -h :
(suspension didn’t work)
total used free shared buff/cache available
Mem: 7.6Gi 4.6Gi 1.6Gi 1.0Gi 2.7Gi 3.0Gi
Swap: 9Gi 1.6Gi 8.4Gi
(suspension worked)
total used free shared buff/cache available
Mem: 7.6Gi 4.7Gi 1.6Gi 1.1Gi 2.7Gi 3.0Gi
Swap: 9Gi 1.6Gi 8.4Gi
It seems to be rather closely linked with the amount of “available RAM”, but there are still situations where I have more available RAM but cannot suspend compared to others, so it’s still nebulous.
My thought is on your swap - and because I do not know exactly swap work in a suspend situation - I am guessing - typing out my thoughts as I think
The keyword being zswap which is allocated in RAM and uses physical partition as next swap medium.
A default Manjaro Linux kernel has swap enabled
$ uname -r
6.15.4-5-MANJARO
$ zgrep CONFIG_ZSWAP_DEFAULT_ON /proc/config.gz
CONFIG_ZSWAP_DEFAULT_ON=y
According to the Arch Wiki
- zsmalloc is in kernels after 6.3 and the Arch default. It is supposed to work well under low memory conditions and it saves more memory. The typical compression ratio is around 3.6.
So when you have 20% of 8G system memory, possibly assigned as swap - with the typical compression ratio the zswap may contain - when full - up to 7.2G worth of swapped out memory - add to this number the memory, which may already have been swapped to physical swap and finally add your GPU ram.
This means that under pressure, there is not enough space within the 10G swap partition and this may have been contributing to your issue.
Given your GPU is Nvidia and judging from the type NVIDIA TU117M [GeForce GTX 1650 Mobile / Max-Q] I am guessing it is an Optimus type laptop and this may create issues I have no experience working with.
I used Nvidia a short while - bought it to test how Nvidia behave on LInux - sold it off again after a couple of years - AMD and Intel only now. I also owned a Thinkpad T550 with a dual Intel / Nvidia GPU (before 1xxx series) arrangement.
Ideas for experimentation
How does zswap react in a suspend situation ( not hibernate ) and how may this collide with the Nvidia GPU’s RAM (I looked up the GPU - it seems to be 4G device) ?
I am thinking - your swap partition is 10G - where the rule of thumb for a minimum swap is RAM + GPU - in this case 8G + 4G = 12G.
Add a swapfile in addition to your swap partition so you have at least 12G physical swap space available and retest if this makes a difference?
If this makes no difference this could be swap wanting to ensure that data in RAM is swapped to disk and because the compressed swap - when decompressed to disk - exceeds the available storage bad things happen - e.g. there is no room for Nvidia RAM?
Try disabling zwap at runtime (as root - use sudo su)
echo 0 > /sys/module/zswap/parameters/enabled
To disable zswap permanently use kernel parameter zswap.enabled=0, rebuild grub
2 Likes
I tested both and still suspension failed (zswap was enabled)
I am out of ideas…
What I do know is - I have no suspend issues with
- a Clevo with Intel iGPU and 16G ram (no swap)
- a Tuxedo with Intel Iris XE iGPU and 32G ram (34G swap)
- a ThinkPad with AMD APU and 32G ram (34G swap)
- a ThinkStation with AMD CPU / AMD GPU and 64G ram (no swap)