Before going into suspend (or hibernate for that matter), user space processes and (some) kernel threads get frozen.
If the freezing fails, it will either be due to a user space process or a kernel thread failing to freeze.
To freeze a user space process, the kernel sends it a signal that is handled automatically and, once received, cannot be ignored. If, however, the process is in the uninterruptible sleep state (e.g. waiting for I/O that cannot complete due to the device being unavailable), it will not receive the signal straight away. If this delay lasts longer than 20s (=default freeze timeout, see /sys/power/pm_freeze_timeout
(in miliseconds)), the freezing will fail.
If it's a kernel thread that refuses to freeze, chances are it is a faulty device driver, but it's hard to tell without looking at the logs.
NFS, CIFS and FUSE amongst others have been historically known for causing issues like that.
Back to your case specifically, your dmesg
should have some details about which tasks failed to freeze and you could go from there. Your pastebins have now expired, but a blind guess would be CIFS/SMB - are you using any of them to access Windows shares for instance?
Freezing of tasks in the kernel is explained here, hope that helps: https://www.kernel.org/doc/html/latest/power/freezing-of-tasks.html