You are not logged in.
"acpi_osi", you could give it a try, also to reset the CMOS (though the BIOS upgrade should™ have don that anyway…)
One more (wild) thing: after rolling back the system, did you re-install the bootloader?
Offline
I tried acpi_osi without success, havn't tried cmos reset yet, will try that later.
when it comes to bootloader: I have a whole system but EFI on a btrfs subvolume. That includes /boot.
I am using grub which I have installed ages ago on EFI partition and I havn't touched that since then.
I do not event mount that partition after boot so it should remain the same over time.
so EFI part was not modified during rollback, but other grub related files lying in /boot were rolled back.
Offline
How much "ages"?
Since we assume that something must have changed but it's not the OS, not the HW, not the UEFI - the bootloader is the last thing I can come up with ![]()
Offline
Around a few years.
Well the only thing that changed before working/not working was me doing update and connecting nvme on usb. Nothing more comes to my mind.
Offline
Did you ever try to plug a regular usb key into the slot where you had the nvme and suspend (with it actually being plugged)?
Offline
Resetting the CMOS helped for a while: I tested suspend straight from the SDDM login screen, and it worked (before, it would always freeze).
Then I tried it after logging in, and it froze. I repeated this a few times, and it was always the same.
That got me thinking, and it seems the issue was caused by OpenRGB. I’m using the Git build version, since the latest stable one doesn’t support my RAM.
Apparently it was messing with something in the UEFI, because as soon as I removed it from autostart and rebooted, suspend started working.
What I don’t understand is why it started happening now—I’ve been sticking to the same commit and haven’t updated it. Maybe something just built up over time.
Anyway, I’ll call it solved.
Thanks so much for your help, Seth—I really appreciate it.
Kudos to you!
Offline