Note Suspend to RAM (Sleep) uses power and will eventually discharge batteries
Suspend to disk does not use power but restart will take more time.
…so suspend to disk is preferred,
You can use both.
You need bigger swap to prevent hangs - your configuration needs more memory = RAM + swap. If you cannot enlarge RAM - enlarge swap.
Better solution is in upgrading hardware.
OP uses destop:
My swap seldom wants to use more than about 50% of its 2.2 GB partition on my 240 GB SSD. Since I migrated to Tumbleweed ‘suspend’ shows this hanging behaviour, and now, after various TW upgrades, even worse ‘screen blank’ enters this same erroneous ‘suspend’ mode. I would gladly extend my swap partition by freeing up some of the 128 free GB space on the SSD if I could find an efficient procedure to make the changes necessary. It looks like I will have to repartition my 240 GB SSD but that sounds like installing everything from scratch. Or am I mistaken?
@hnimmo If you have secure boot enabled, there is no suspend working, it is blocked…
I have no swap, suspend ( to RAM) works fine . If you need swap, try out zram.
If I understand you correctly, these are two alternatives.
1, BIOS setting to enable secure boot
or
2. Suspend to RAM, of which I have about 3.6 GB (Cache 1.3 GB, whatever that means!) How do I use this alternative?
PS. I’m not clever enough to use artificial intelligence.
@hnimmo Well is secure boot enabled or not, you need to check your system BIOS?
So I have two systems here, one is a HP Stream with only 2GB of RAM, no swap and running MicroOS/Hyprland/Intel GPU and a new desktop setup running Tumbleweed/GNOME/Nvidia GPU, this has 32GB of RAM and no swap. Both suspend fine and return from suspend. Neither run Secure Boot.
Suspend is not blocked. If memory allocation is the problem, I might try changing it if it’s not too risky. I just need a reliable procedure and to be pointed in the right direction.
@hnimmo Could be related to your older hardware. What does the output from /lib64/ld-linux-x86-64.so.2 --help show?
It shows a complete help text for the ld.so interpreter. Is there something specific I should try?
@hnimmo likely the age of your system… a V1 CPU, probably easiest solution is a fresh install and create your swap etc, else consider getting some new hardware?
~> /lib64/ld-linux-x86-64.so.2 --help | tail -n13
--version output version information and exit
This program interpreter self-identifies as: /lib64/ld-linux-x86-64.so.2
Shared library search path:
(libraries located via /etc/ld.so.cache)
/lib64 (system search path)
/usr/lib64 (system search path)
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3
x86-64-v2
@hnimmo Yes, AFAIK, no output indicates V1…
My development system’s output;
Subdirectories of glibc-hwcaps directories, in priority order:
x86-64-v4
x86-64-v3 (supported, searched)
x86-64-v2 (supported, searched)
Are you saying that TW will not work with my ageing HW? Should I revert revert to Leap 15.6 and continue with Leap 16 when it gets released?
Your CPU won’t work on Leap 16.0 there will be no support for your system. On Tumbleweed I suspect you will always have issues with old/legacy systems
It means 16.0 will not support your Pentium D. Plans to terminate v1 support for TW in the foreseeable future have not been clearly expressed, so our GX620s will remain technically viable at least for some time……
@mrmazda True, but at the expense of users like myself with newer hardware for features and security enhancements 
@hnimmo I do suggest you look around at what newer hardware is available for your requirements, there are many Mini PC’s around that may fit your needs and any price restraints.
So, on the one hand, my current configuration is not, and will never be, compatible with TW. On the other hand, it will also not be compatible in future with Leap 16. At least, if I revert to Leap 15.6, I will get a few months of respite to consider the alternatives.
I don’t see that “never” has yet been proven, but 15.6 will be supported at least until the end of November 2025. With 16.0 release expected in October, it’s looking like it will be well beyond November before 15.6 support actually ends.
Well, the main thrust of suggestions have been directed at my ‘ancient’ (but still working) hardware and/or reallocating memory/swap space. For the latter I would appreciate hearing how to do it efficiently with minimal risk. But as that seems not to be forthcoming, I have to assume that, even if I were to venture into the sphere of more swap/less memory with all it entails, I may still not have resolved this issue problem (which didn’t exist when I was running Leap 15.6).