Is it from suspend or sleep mode?
If it is suspend, make sure your SWAP partition/file is a little larger than your RAM.
For suspend, can’t tell. The logs tell us nothing here.
Thanks @Jorg_Mertin for the FUP.
I guess it is suspend, because it is after having reopened the lid:
/etc/systemd/logind.conf:
#HandleLidSwitch=suspend
This said, I have 32Gb of RAM and 2GB of swap:
vmalep@framework:~$ free
total used free shared buff/cache available
Mem: 32016992 6473120 21463144 140424 4080728 24937572
Swap: 2002940 0 2002940
I will increase the swap anyway and see how it goes…
ref:
vmalep@framework:~$ free -h
total used free shared buff/cache available
Mem: 30Gi 6.4Gi 20Gi 114Mi 3.9Gi 23Gi
Swap: 32Gi 0B 32Gi
Best regards,
Pierre
If the laptop crashes again, I will resume this topic, but it seems to me that the issue was as swap file to small to store the RAM when the computer was ongoing on sleep mode.
Thanks @Jorg_Mertin for your support!
Dear all,
Since Jan 24, I have been using the computer without any problem of that kind.
Recently, I have resinstalled Linux on the computer. First Fedora, which created a BTRFS in place of ext4. Then I replaced Fedora by Ubuntu again (24.04, and because with Fedora, applications were crashing all the time), but maintaining the BTRFS to see how it goes.
This time, in place of a swap file (not possible with BTRFS), I created a swap partition:
And the issue of Ubuntu crashing upon resuming from suspend reappeared and it now very frequent…
I am planing to reinstall the all computer and switch back to ext4 fs like before. I hope the issue will disappear.
To be followed up…
BR
Pierre
Let us know how things went this time, good call on a fresh install with ext4 as a filesystem.
I crated a separate topic because I thought my issue was different, but it seems more and more like this one as I find out more.
I can take that down and move the information here if that’s the thing to do. For now I’ll give a summary of my corroboration of the issue.
I’m on Fedora 40, which uses btrfs. I haven’t used any other operating systems on the device. After opening the computer from suspend, less than 20 seconds after login (and interacting with the previously open applications as usual), it goes black and shows the splash screen and login page anew. This doesn’t happen every time. My working theory is that it happens after the first suspend-open since the computer was last fully restarted or shut down, and doesn’t occur on subsequent suspend-opens on the same session. I haven’t done it enough to confirm.
I also encounter the exact issue frequently. I am using Ubuntu 22.04 on FW13 AMD edition. I originally suspected that the problem originates from the connection to a power adapter, but I can not reliably reproduce the issue either with or without. I read the log in journalctl but found nothing suspicious. So frustrating.
Upon seeing this, I wonder if the problem has something to do with btrfs? So do both of you, I also have a btrfs setup on my Framework. Is there btrfs-related issue that might cause abrupt reboots? I would like to switch to ext4 in the future to help diagnose this issue.
As far as I understood, the problem comes from a too small swap (it must be bigger than the RAM). And with BTRFS, it is not possible to create a swapfile, only a swap partition. I had tried that solution and it was still not working.
I reinstalled Ubuntu using ext4 and then created a 32Gb swap file (I have 32Gb of RAM), but the computer was still crashing. I then created a 64Gb swap file and since then, no problem…
I have a 16GB ram and an 18GB swap file but it is still happening. By the way, do you have any possible guess of how a small swap triggers a reboot?
I’ve since experienced this in a greater time range, between seconds after login and minutes. Not yet happened twice in the same session, but it’s happened after the first and second suspend of different session. Whether it’s btrfs, swap, or a different issue, I wonder why it’s only now a problem. btrfs gets updated in newer kernels, but I stay relatively up to date and this definitely wasn’t a problem for me in January.
Eventually, after the reboot, you should recover the journal/logs entries?
sudo journalctl -b 1
will show you the log before the reboot, -b 2 from before the 2 last reboots and so on.
Eventually there is an indication on why the reboot happened?
I have tried reading journalctl output again and again but have not found any error. Even not a slight error message. I guess that if there was really an error, the error log had not been flushed to the hard disk.
I tried disabling the swap entirely. Did not work either.
1 Like
Check this out …
Eventually that is related?
2 Likes
My distro just got 6.10 and I haven’t been affected by the issue since, but it’s been less than a day. Will update if the suspend-crash happens again.
The wake-crash happened again a few times, so 6.10 definitely didn’t solve the issue.
Having this issue too for a few month… Happens every 20-25 wake from suspend instances, running Linux 6.10 but this has been going on long before 6.10 release. Machine just crashes and reboots, last log are always from suspending the computer, nothing from wake and afterwards.
For me it’s 100% of the time. Though it’s probably worth noting that sometimes instead of black screen -> reboot it’s frozen screen/graphical glitches -> reboot
Can also confirm that no changes to files in the brief wake period persist after the crash.
Not unless there already was one, no.
@Max_Pearce_Basman Alright…Nevermind, then. I had one set (i.e. storing the disk encryption passphrase in the TPM), removed the BIOS Boot PW and so far, so good (been only a few days). I read in the Release Notes from the 0.0.3.5 FW update [1] that there has been an issue where the system hangs and the EC resets the system if it can’t access the nvme after resuming from suspend.
But anyhow, that also wouldn’t explain the artifacts you describe you’re seeing shortly before system reset.