I received a new Framework laptop recently, and experienced right off the bat an odd issue I’ve seen reported about on this forum a couple of times : when powering back from sleep mode, either by pressing the button or by raising the lid, the screen stays black and the computer remains unresponsive. I need to force its shutdown to be able to use it again. The issue occurres weither on battery or plugged in.
Framework 13 DIY edition
AMD Ryzen 5 7040 series
Kingston NV2 NVMe 1TB SSD (bought in 2023)
Debian 12
To clarify, I reused the SSD from a previous laptop that ran another distro. I used the Debian ISO installer to repartition it.
I’ve already ran an EFI Shell update. This did not have any effect on the issue at hand. Firmware is also up to date. I hope I did well by creating a new topic, since I haven’t found the solution I’ve been looking for in other posts. For now, I’ve been using the hibernate mode during my daily use, but you’ll understand this is way less practical the the sleep mode.
Edit: this is incorrect advice; please disregard it.
s2idle is known to cause problems with sleep on the framework. It’s suggested you switch to deep. There should be instructions in a few different threads here on how to do that.
I first ran the python script you created, because I wasn’t sure where to start to manually update the amdgpu firmware. The results pushed me in that direction regardless by indicating the the “AMDGPU firmware is missing”, while also warning that “Device firmware checks unavailable without fwupd gobject introspection”. More precisely, it failed to load “gc_11_0_1_mes_2.bin with error -2”.
I then proceeded to the manual installation of the firmware by following a loose guide from some forum. I copied all the .bin files found on the kernel repository on gitlab.com into my /firmware/amdgpu/ directory. I used the terminal in my first attempt, logged as root admin.
I might have messed up there, because after rebooting and trying (unsuccessfully) to enter & emerge from sleep, I ran the script again just to arrive at the same diagnosis. However, at this stage, the bin files currently present in the directory appear to be the most recent, and any further attempt to re-replace them changed nothing.
Kingston doesn’t offer a solution to update the SSD firmware outside of Windows. If it comes down to it, I will buy another drive and build a new system.
Thanks for any following advice, especially for updating the amdgpu firmware. I understand you can’t teach me the ropes to all the hardware and firmware operations you are suggesting to fix my issue, but you might have understood that I am a beginner when it comes those. The learning curve is steep!
If you’re a beginner at all this, I’d strongly suggest you start with Ubuntu or Fedora. They both have modern hardware support out of the box, are actively supported by Framework (you can call in if something is wrong) and are generally much more beginner friendly. Think of Debian as aiming for stability, but to the level of neglect for hardware support. Think of Arch as aiming for bleeding edge but to the level of risk to things breaking all the time (rolling release model). Ubuntu and Fedora are the happy medium.
That being said if you want to stick with Debian and the script still reports an issue it is probably that you need to rebuild your initramfs with the updated firmware. If the GPU driver is within the initramfs then it will load the firmware also in there.
I will persist in my ambition to make Debian work on my FW13 a little more by rebuilding initramfs, or attempting to. I’ll give an update if I succeed.
I had been using Zorin for a year before switching over to Debian 12 this winter. With this install, it is my first time using the stable-branch with bleeding-edge hardware, and I think I get now why so few distros have opted for that update philosophy. Anyway, guess a Ubuntu install might be waiting for me around the corner, in the end.
In Ubuntu (I think debian works the same) there is an option to keep a backup of the previous initramfs when you update it. It might save you some trouble in you break anything. Set backup_initramfs=yes editing /etc/initramfs-tools/update-initramfs.conf.
This sounds about right. The right directory should be either /usr/lib/firmware/amdgpu or /lib/firmware/amdgpu.
I don’t know if the following can help you. I wrote a script when I was on Ubuntu 23.10 to update the firmware after the old firmware was overwritten by some apt upgrade. Here the content of the script. I’m not sure it will work on Debian.
#!/usr/bin/bash
WORKING_DIR=$(mktemp -d)
FW13PHOENIX_FIRMWARES="dcn_3_1_4* gc_11_0_1* psp_13_0_4* sdma_6_0_* vcn_4_0_*"
FW_DIR="/usr/lib/firmware"
cd $WORKING_DIR
echo Fetching...
wget -c https://gitlab.com/kernel-firmware/linux-firmware/-/archive/main/linux-firmware-main.tar.gz
tar -xf linux-firmware-main.tar.gz linux-firmware-main/amdgpu
cd linux-firmware-main/amdgpu
echo Compressing...
mkdir compressed
for fwfile in $FW13PHOENIX_FIRMWARES
do
echo $fwfile
zstd -c -18 $fwfile > "compressed/$fwfile.zst"
done
echo Copying...
if [ ! -d "$FW_DIR/amdgpu.bak" ]
then
echo Copying as backup...
sudo cp -rl "$FW_DIR/amdgpu" "$FW_DIR/amdgpu.bak"
fi
sudo cp compressed/*zst "$FW_DIR/amdgpu"
echo Initrd...
sudo update-initramfs -u -k all
The issue was fixed! I thought I’d go over the steps I took for future troubleshooting (on a FW13 Ryzen 5, running Debian 12).
I. updating amgpu
I copied the most up-to-date kernel firmware for AMD GPUs (found on the linux-kernel git) over in my local /firmware/amdgpu/ directory. More details in previous posts.
II. updating initramfs
I ended up simply updating (rather than rebuilding) the initram filesystem using the command below, both found in Debian and Ubuntu.
sudo update-initramfs -u -k all
As I understood it, this command will check & update the initramfs for every kernel, returning an error if not finding what it is looking for. More info here. I let the script do its thing, propping up a great deal of ‘‘missing file’’ errors.
After a reboot and some testing, it appeared to do the trick! I can now use the regular sleep mode, weither automatically or manually, without encountering an unresponsive black screen upon powering it back.