I got a Framework 16 laptop two weeks ago. In that time, I’ve had two situations where the laptop failed to resume from suspend. I researched this and found some similar topics:
I am uncertain if these issues match what I have seen, though. The symptoms are:
Intermittent and fairly rare; maybe 2 out of 25 suspend/resume cycles.
The power LED pulses slowly, as is normal for suspend.
Pressing the power button has no effect. My only recourse is to hold the power button down for full power-off.
On the second occasion, the laptop was already quite warm; didn’t notice either way on the first occasion.
Does this match any known issues with suspend/resume for AMD on Linux, or is there a hardware issue?
I tried amd_s2idle.py as mentioned elsewhere. If I understand correctly, this is a test script to exercise the suspend-to-idle functionality (as suspend-to-RAM is not supported on this platform). The script was able to run without incident. I ran a total of 25 cycles on battery power and 20 cycles on AC power. I have not yet been able to deliberately induce failure in any way.
…but I don’t think I can conclude anything from not seeing the message here; the message may have been printed by the kernel but systemd never had chance to write the message to the journal.
I think that is a red herring, though. The warning is also present in the logs for the current boot, which has not failed yet.
Sometimes I plug in a TV via HDMI; I may suspend with the HDMI cable connected and resume with the cable disconnected. I haven’t been able to induce a failure by doing that, though.
Userspace triggers a “mem_sleep” via writing mem to /sys/power/state and the kernel chooses the actual mechanism depending on /sys/power/mem_sleep. Since s2idle is the only available value on this laptop, suspend-to-idle is what is used.
In other words, s2ram triggers whatever kind of “mem” sleep the kernel is configured to use, same as other utilities, e.g. amd_s2idle.py:
I see now that the package for s2ram is no longer maintained in Debian, so I’m switching to systemctl suspend anyway, but I don’t think that should matter for this problem, since the actual suspend is handled by the kernel.
I had been using the laptop on battery for a short while–maybe 20 minutes. Then I suspended it and plugged it in. A bit later, I unplugged it, then plugged it in again. Then I came back about 15 minutes later and found the laptop was warm. I checked the power draw at the wall: 16.3 +/- 0.3 W. The laptop was unable to resume.
Normal suspend-to-idle power draw, when the battery is charged, seems to be 1.3 +/- 0.3 W.
Suspecting the failure had something to do with unplugging and replugging power, I did about 5 unplug/replug cycles while the laptop was suspended. This did induce another failure. Unfortunately, I was not able to repeat this again on two more attempts, so either the failure was a coincidence or I have not yet found the right conditions.
Both failures today were after suspending via systemctl suspend (nothing to do with the s2ram utility).
That thread went in a few directions, but the upshot for the suspend/resume issue is here:
Something I think notable about your system is you are using two SSDs
which is (relatively) uncommon. Have you already updated the firmware
on both SSDs to the latest?
If so; would it be possible try to run with just one SSD for a week or
so and see if this issue comes back? If it doesn’t come back there
could be a BIOS bug with how it’s handling your combination of the 2x
SSDs and you should report it to Framework.
I updated the SSDs to the latest firmware and the issue was still present.
I then tried using only one SSD for several weeks; no issue. Then I tried switching to use only the other SSD for several weeks; no issue. Then I switched back to both for several weeks… and there was no issue at first, but then I hit the same problem. Just once.
So for me now, the issue still seems to be present, but it’s so rare that I don’t have any hope of being able to test it.
I’m still running BIOS 3.0.3; I hesitate to update because it would not be possible to roll back.
By now I have a hypothesis that this is temperature related and the problem (mostly) went away once wintertime arrived and my household temperatures became lower. If the problem comes back when the weather gets warm again, that would support the hypothesis. It’s still just a hypothesis, though.
yes and since a few days also a usbc plug-in card with 1TB memory for daily backups. So for me I wouldn’t say it’s the temperature.
It’s just extremely annoying at the moment that I have so many problems with the system, graphics card is not recognized or only sporadically, the suspend and system freezes every now and then.
For me, the problem only occurs when the supsend is on for a longer period of time. For example, if I leave the PC in supend overnight, I can no longer start it the next day. It also seems to make a difference whether it goes into supend automatically or whether I activate it manually.
I’ve had the problem happen to me twice since I last updated this thread. The weather around here has still been pretty cold, so that tends to disprove my earlier hypothesis about the problem being temperature-induced.
On the most recent time, while the laptop was still powered on, I partially disassembled the unit, as far as taking the midplate off. I wanted to see what was emitting the heat, and the heat was definitely coming from the CPU. The CPU heat pipes were quite hot–almost painfully hot if I left my finger in place.
Nothing else felt substantially warm. I specifically checked the memory, SSDs (the top one, at least), battery, and Wi-Fi card.
One other thing I noticed, once I took the keyboard off but before I took the mid-plate off: the two side LEDs were steadily blinking red. I don’t know if the blinking started before or after I began to disassemble the laptop. The light from each LED is channeled to such a tiny dot on the side of the laptop that I could easily have never noticed before. I will check for this next time the laptop fails to resume; maybe the blinking LEDs are indicating something useful for diagnosis.
For me, the problem only occurs when the supsend is on for a longer period of time.
At one point early on, I was able to induce the problem immediately. This seemed to have been random, though; I’ve never been able to reliably make the problem occur.
