I believe you should see things similar to this in your dmesg before suspend:
[196792.161548] PM: suspend entry (deep)
[196792.256340] Filesystems sync: 0.094 seconds
[196792.264782] Freezing user space processes
[196792.268707] Freezing user space processes completed (elapsed 0.003 seconds)
[196792.268712] OOM killer disabled.
[196792.268712] Freezing remaining freezable tasks
[196792.270024] Freezing remaining freezable tasks completed (elapsed 0.001 seconds)
[196792.270034] printk: Suspending console(s) (use no_console_suspend to debug)
[196792.289187] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[196792.289245] sd 0:0:0:0: [sda] Stopping disk
[196792.693420] ACPI: EC: interrupt blocked
[196792.725166] ACPI: PM: Preparing to enter system sleep state S3
[196792.725260] ACPI: EC: event blocked
[196792.725260] ACPI: EC: EC stopped
[196792.725261] ACPI: PM: Saving platform NVS memory
[196792.725271] Disabling non-boot CPUs ...
[196792.726675] smpboot: CPU 1 is now offline
[196792.728588] smpboot: CPU 2 is now offline
[196792.730505] smpboot: CPU 3 is now offline
And after you resume, you should probably see:
[196792.732980] ACPI: PM: Low-level resume complete
[196792.733026] ACPI: EC: EC started
[196792.733027] ACPI: PM: Restoring platform NVS memory
[196792.733658] Enabling non-boot CPUs ...
[196792.733708] x86: Booting SMP configuration:
[196792.733709] smpboot: Booting Node 0 Processor 1 APIC 0x1
[196792.734619] CPU1 is up
[196792.734656] smpboot: Booting Node 0 Processor 2 APIC 0x2
[196792.735388] CPU2 is up
[196792.735422] smpboot: Booting Node 0 Processor 3 APIC 0x3
[196792.736181] CPU3 is up
[196792.737933] ACPI: PM: Waking up from system sleep state S3
[196792.738183] ACPI: EC: interrupt unblocked
[196792.756019] ACPI: EC: event unblocked
[196792.756917] sd 0:0:0:0: [sda] Starting disk
[196792.760770] i915 0000:00:02.0: [drm] [ENCODER:94:DDI A/PHY A] is disabled/in DSI mode with an ungated DDI clock, gate it
[196792.760776] i915 0000:00:02.0: [drm] [ENCODER:102:DDI B/PHY B] is disabled/in DSI mode with an ungated DDI clock, gate it
[196792.760779] i915 0000:00:02.0: [drm] [ENCODER:110:DDI C/PHY C] is disabled/in DSI mode with an ungated DDI clock, gate it
[196792.762383] nvme nvme0: Shutdown timeout set to 8 seconds
[196792.769658] nvme nvme0: 4/0/0 default/read/poll queues
[196793.071565] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[196793.072268] ata1.00: supports DRM functions and may not be fully accessible
[196793.079114] ata1.00: supports DRM functions and may not be fully accessible
[196793.086454] ata1.00: configured for UDMA/133
[196793.086876] ata1.00: Enabling discard_zeroes_data
[196793.174858] OOM killer enabled.
[196793.174859] Restarting tasks ... done.
[196793.177687] video LNXVIDEO:00: Restoring backlight state
[196793.355195] PM: suspend exit
[196793.355271] elogind-daemon[5005]: System resumed.
[196797.194211] wlp2s0: authenticate with 38:94:ed:15:96:aa
[196797.203960] wlp2s0: send auth to 38:94:ed:15:96:aa (try 1/3)
[196797.211953] wlp2s0: authenticate with 38:94:ed:15:96:aa
[196797.211956] wlp2s0: send auth to 38:94:ed:15:96:aa (try 1/3)
[196797.216989] wlp2s0: authenticated
[196797.223168] wlp2s0: associate with 38:94:ed:15:96:aa (try 1/3)
[196797.225385] wlp2s0: RX AssocResp from 38:94:ed:15:96:aa (capab=0x11 status=0 aid=11)
[196797.225475] wlp2s0: associated
[196797.283225] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes ready
I assumed you should have installed elogind and put into “boot” runlevel. Recently I reinstalled one system with Plasma but nothing pulled into elogind, everything seems to be weird. Mind you, those log I didn’t pull them off Framework, but two working Gentoo OpenRC system.
Thank you @Kings for your answer. Unfortunately, nothing is logged when suspending and resuming. For me, maybe it’s a SSD-related problem, as no log is written?
I’ve just tried another distro: Manjaro Gnome, to see how it is working, comparing to Fedora 38 and my Gentoo. I have suspend and resume problems in Manjaro too: the first time it was able to resume properly, but my battery discharged drastically during suspend: from 60% to 15%! And the second time, resuming didn’t work at all: total freeze like on my Gentoo.
For now, the only distro which supports greatly my Framework is Fedora 38: all is working, even the ambient light sensor (not in Manjaro and Gentoo), but same battery draining problem during suspend.
@Kings Reminds me of my first trials with Linux (Mandrake, old Fedoras, Debian…) 20 years ago Always had suspend problems. Seems like, as for now, suspend is not quite well supported on Framework hardware as I can see on this forum…
@Mapleleaf Thank you! I just tried your script: works great, the laptop goes really on sleep (power button led goes off), and resumes directly on desktop as you said. But after resuming I am not able to do anything: I/O errors when I want to execute any command, and a desktop notification when I want to launch any app: Execution of child processus /usr/libexec/gio-launch-desktop failed (I/O error)
Only thing I can do: hard rebooting…
For me, this is clearly a problem related to the SSD: looks like the system is unable to read/write anything when resuming…
@Phil I tend to think that the machine is suspending well - as your Fedora, and the test you did are working. The software is the the culprit on your Gentoo installation. I highly suspected that something is missing on your fresh Gentoo install.
Looks like gio-launch-desktop is part of Gnome, and I don’t even have it on my system (by the way, do you have this file?).
Maybe you could try with an other DE?
Personally I’m on XFce. And yeah I use OpenRC just like you.
@Mapleleaf Thank you for the other thread. I think I have a SSD incompatibility/bug issue. My Gentoo is installed on a M2 I already had before purchasing my Framework. But my tests in Fedora and Manjaro were done with the M2 purchased at Framework…
Ok, in this case it would be interesting to see what happens if you copy your Gentoo install over to the Framework SSD.
In particular using the s2ram script, which I believe gives the most control over what’s happening.
@Phil That sucks…
Could you also try a Live Ubuntu on a USB stick?
If you contact support, that’s among the diagnostic steps that they will always ask.
@Mapleleaf Alas, same problem with a live Ubuntu: no real suspend… But it resumes well. So I think the resume freeze is related to the SSD. I have to try Ubuntu installed to confirm that.
@Phil Have you had a chance to try, still on the live Ubuntu, the s2ram script?
That would test the real suspend.
At that point, if you still have problems, it would not be a SSD issue, but a mainboard one.
@Phil There seems to be a known problem with the touchpad right after a wake from a suspend, on Ubuntu. I didn’t know, just discovered that.
Here is the workaround (some unloading and reloading of kernel modules):
I discovered it here:
What was exactly your “freeze” symptoms after a s2ram? Can it be consistent with just the touchpad not working?
Since I got mentioned and this reached my inbox, I’ll add my 2 cents.
Let’s zoom out 5 levels first and tackle the expectation that the system should suspend to RAM (S3) and resume correctly like our ThinkPads from 10 years ago.
Intel no longer supports S3 on their chips. Yes, it’s enabled and it works on the 11th gen Intel on Framework but even then it takes a strangely long amount of time to resume. So this is not to say that S3 is impossible on the Framework, it is possible. However Intel seems to be officially giving up on keeping it working via chip and driver implementation. Likely because herding all the smaller vendors on the mainboard to get it working correctly for their chip, firmware and driver has always been a problem. Instead the expectation being set is that S0iX should be used in a suspend-only or suspend-then-hibernate configuration. In other words, do what Windows does. Intel is working on getting S0iX to consume significantly less than traditional S0. In fact on the Framework S0 and S3 are somewhat close in power consumption. Heck you can get ~3%/hr power consumption on idle with the screen brightness to lowest.
What I did is to stop fighting the man. I went with suspend-then-hibernate setup using S0iX. I haven’t had a problem since. The drivers get reloaded as they do on a normal boot so none of their S3 bugs get hit. Resume from hibernation takes marginally longer than the slow resume from S3 and the laptop can spend as long as the CMOS battery lasts in hibernation.
With that, my two cents are - if you really want S3, you can get it working, but the benefits might not be as pronounced as they used to be 10 years ago and S3 is already being phased out.
PS: I have no idea how to get suspend-then-hibernate configured on OpenRC but here’s how it’s done (SaltStack code) on systemd. Actually scratch that. It’s not very clear from that source code. Here’s the doc.
Always had suspend problems. Seems like, as for now, suspend is not quite well supported on Framework hardware as I can see on this forum…