Which release version?
(if rolling release without a release version, skip this question)
(If rolling release, last date updated?)
Which kernel are you using?6.18.2-arch2-1
Which BIOS version are you using? 04.02
Which Framework Laptop 16 model are you using? (AMD Ryzen™ 7040 Series)
randomly my framework will basically do screen tearing (see attached ) and i cant figure out why. i have tried making sure the eDP cable is connected, i dont fully know what else to try.
This looks exactly like the graphical corruption I got when I was being bit by the infamous FW16 GPU freeze bug.
In my case, it took a mainboard replacement to resolve it. Some people have reported success with kernel arguments or BIOS updates (though it seems like you’re running a recent enough version that it should be fine?). There are discussions about the issue here, without really a clear resolution:
You might try the kernel arguments that other people have tried, or you might talk to Framework support about the issue. One way or another it definitely seems to be an issue on Framework’s side.
That shouldn’t cause GPU errors. At most it should trigger freezes without any logs indicating that, or at least only logs about not being able to transmit the data. Unless AMD really made the error message the amdgpu driver prints illegible, that shouldn’t be the case.
My motherboard will soon be replaced too and pulled aside for testing for the more and more wide spread audio problem. I will try to have them test that too. It’s technically even reproducible on a Fedora 43 live ISO, though the odd thing is it happens less frequently (might be due to kernel version), and if you are unlucky, it occurs before you are able to set up an ssh connection to collect logs. It happened three times on me already on the ISO, neither time I was able to collect logs. And since it only triggered on my normal Debian install, even when I didn’t shut down the PC during the night, but have it suspend so it runs the same environment for multiple days. That’s just frustrating.
also, but closing the screen and letting it lock, the issue is fixed without rebooting. but it will happen again. its just a temp fix w/o rebooting. im going to try and lock the screen with keybind to see if that also has the same effect or only when it suspends.
Yeah, that sounds like what I had. Some things made it more or less likely (especially kernel version), for some reason.
For me, connecting an external monitor gave me a reliable way to debug, since the freeze only affects the internal display. When things froze up I could clean up the system and then restart, or poke around for debugging via the external monitor for as long as I wanted to.
Yeah, I had network flakiness on my originally-shipped mainboard too, even after I invested some money into an AX210 network adapter thinking that the crappy Mediatek adapter that came with it was the reason.
I think you should talk with Framework support, I’m not expert on this but it sounds to me like you need a new mainboard.
I wished an external screen was also a solution on my situation, but sadly it stayed dark (at least over DP). Otherwise that would have indeed made things much easier.
Unfortunately I have also been hit with a brand new Framework Laptop 16 with screen flickering/ghosting, see linked video.
I also have one laptop from around Februari 2025 that doesn’t show this issue.
I was trying to update the firmware using a pxe loaded debian trixie (safe mode, secure boot disable) with fwupd. No numpad, no keyboard and no bios in devices list.
FYI: if you do a pxe boot, then there is no ESP partition. You get a nice warning from fwupd about that.
