I’m quite convinced - wether this is a hardware or a software issue - this must be an issue that’s rooted in the mode the GPU is in. Once this issue appears, it will continue appearing within minutes even after a reboot if I don’t turn off the device for at least like half an hour, reproducibly. Though there’s exactly one scenario that seems to be reliably preventing it: playing a video. I can’t tell if it just needs to be in the foreground or if it needs to be full screen (I only have it playing full screen), but no matter how I play it, be it locally through mpv or like a YouTube video through Firefox, it will always prevent it from happening. Though I can’t tell if watching the video or if the hardware accelerated playback is doing the fix. Also, in tty mode it barely ever happens.
EDIT: just having the video play in the foreground is enough, doesn’t need to be fullscreen. Though I haven’t yet tested software vs hardware decoding.
And I can confirm this for Debian Testing, Gnome (up to 49.2 currently) and BIOS 4.02, on basically any kernel of the past year or so. Though I haven’t tried suspending for fixing it yet, all I tried was rmmod -f amdgpu && modprobe amdgpu (which either fails or takes a very long time to complete, no idea) and just using the SysRQ key combination for rebooting (which fails sometimes, while the combination for shutdown basically never works).
Yeah. That tracks with my experience back when I was having this issue. I’ve had even stranger manifestations of it, where it would crash with graphical corruption, I would power off and do something else for an hour, and then when I powered back on the system the corruption would be overlaid on the screen over top of the bootloader and whatever else I was doing with the machine.
That was what apparently finally firmly convinced Framework support that it was a hardware issue
I get that this is frustrating, but I dont think you are hitting the bug, and if you are, its not really on framework’s end. Its on the developers for the distro you are running. Have you tried to create a bugzilla for Fedora? Fedora Bugzilla link
I can definitively say that this was either a hardware or BIOS issue for me when I ran into it, not a software issue. It happened on Ubuntu live CD, and replacing my mainboard with a new one Framework shipped me fixed the issue still running the same software.
Upgrading the old mainboard to BIOS 03.07 also fixed it, so thanks to Perri for the recommendation, but the new mainboard fixed it apparently on all BIOSes in addition to some other issues it was having.
I’ve been having this issue as well. I tested just running this laptop without an external monitor the internal display would freeze plugging in a monitor I could use my laptop. If I would suspend the laptop by closing the screen and reopening it would fix the issue. Initially I was having this issue on Ubuntu then I tried switching over to Bazzite to see if it would fix the issue it still occurs. The display freezes when playing games such as Elden Ring or doing a google meets call.
I’ve now created an issue at Framework’s official firmware issue tracker. No idea if this is caused by Linux, firmware/BIOS or hardware, but this has been around for too long, and the fact that I haven’t heard of any other AMD 7040 series laptops being affected suggests Linux isn’t really the cause. Once I finally get a working replacement mainboard (from another issue) I’ll report back if that was able to fix things.
