Grundik

I've noticed, that probability of failure increased, if memory-heavy applications were loaded, and swap space intensively used, even if they are already unloaded at the time of suspend. Maybe something critical could get swapped out?..

More than week have passed, vhba module is loaded, cdemu daemon and manager are not (but was loaded once, to talk to the module initially) — not a single hiccup occured.

P.S. clarification: systemd cdemu daemon and cdemu kde manager. I'll disable both of them.

VHBA module, and cdemu kde daemon. 2 virtual drives, but no images loaded in them. No extra optical drives in system. I'll disable daemon, and report back in whats the result.

I'm not sure, if this is related to vhba, but after I installed it back into system, I've managed to get this freeze (it was recoverable, unlike previously): kernel: PM: suspend entry (s2idle) kernel: Filesystems sync: 0.029 seconds kernel: Freezing user space processes kernel: Freezing user space processes completed (elapsed 0.004 seconds) kernel: OOM killer disabled. kernel: Freezing remaining freezable tasks failed after 20.009 seconds (0 tasks refusing to freeze, wq_busy=1): kernel: Showing freezable...

Its very weird issue, I agree. It probably occurred sometimes before, but I cant confirm it was issue in vhba. System occasionally just freezes going to standby, and Im using s3idle. After kernel update from 6.10.0 to 6.10.4 it started to occur quite often, like once a day. And thats the only lead I had: one time system do not get totally frozen, I was able to switch to console and see the logs, and that was there. I tried to remove vhba+cdemu, and there already 3 days without issues. Obviously its...

Suspend freezes PC with kernel 6.10