In the past month or so, I have been having increasingly severe graphical glitching, freezeups, and crashes. I had a perfectly working graphics setup that let me play most things in Steam, Wine, linux native games, etc just fine on either the iGPU or my nvidia eGPU, until all this started. Now, the Steam UI will not even reliably launch, let alone actually get into games using any version of proton. Lutris UI launches, but again any “3d” game I try crashes shortly after launch or actual level load. “2d” games (i.e. Freeciv, Endless sky, etc) seem to be okay. Crash occurs either with iGPU in use (eGPU not connected), or with nvidia 1050Ti eGPU connected and verified actively processing the DE, Steam, and games via nvidia-smi. Crash has progressed to affecting other programs as well (Vivaldi browser, orca-slicer, etc). The DE sometimes recovers from the freeze, but usually the graphic glitching is followed by a soft crash back to tty, or complete hard freeze of whatever DE/OS I am trying. I have noted the graphics issues in each of these DE’s:
- Hyprland (0.42-0.45), wayland native
- Gnome-shell 47.1, both wayland and x11 session
- KDE/Plasma (6.1 to 6.2), both wayland and x11 session
- Windows 11 24H2
(Wayland or X11 session in use was verified via loginctl show-session <ID>
)
The graphics glitch looks either like random colored pixels sprinkled all over the screen, or blocks being overlayed on the screen (think damaged avi video file look). See example pictures of the graphic glitch at end of this post.
I am not seeing anything actionable in dmesg or journalctl on any system, but here are some relevant crash outputs anyway:
- Hyprland crash report: Hyprland received signal 6(ABRT)Version: 4520b30d498daca8079365bdb909a8dea38e8 - Pastebin.com
- Journalctl from same crash in Hyprland (edited/sanitized): > cat hyprlandCrashReport5211-journalctl.txt | grep -i -a20 -b20 "5211"...1 - Pastebin.com
- dmesg from same crash (edited): [ 3031.257680] x86/split lock detection: #AC: CJobMgr::m_Work/60631 took a split - Pastebin.com
Which Linux distro are you using?
Symptom appears in each of the following OS’s, when run as a bare metal (not virtual machine) install.
- fully updated arch linux x86_64, and
- fresh install then fully updated Fedora 41, but only tested iGPU, no Nvidia drivers loaded or eGPU connected, and
- fresh install then fully updated Win11 24H2, with Framework supplied 13th gen driver pack for iGPU, no Nvidia drivers loaded or eGPU connected
Which kernel are you using?
Symptoms appear in all of:
- linux (earliest I noticed the issue was circa 6.11.2, but continues with 6.11.6)
- linux-lts (circa 6.6.58 to 6.6.60)
- linux-zen (circa 6.11.6)
- linux-hardened (6.10.? to 6.11.7)
- Windows 11 kernel that comes with 24H2, no idea the version/build number though
Therefore I really doubt this is kernel related at all. OpenGL, Mesa/Vulkan, Intel proprietary drivers, etc certainly suspect, but probably not kernel.
Which BIOS version are you using?
from lshw:
description: BIOS
vendor: INSYDE Corp.
physical id: 0
version: 03.05
date: 06/04/2024
size: 128KiB
capacity: 16MiB
Which Framework Laptop 13 model are you using?
FW13 i5-1340p is my daily driver. Single 32GB lexar RAM module which passes all memtest probes with no errors. Crashes occur with and without AC power applied, with and without expansion cards in, etc.
The graphics problem does NOT happen if I move my SSD into an i5-11th gen mainboard (running BIOS 3.19 I think). Graphics problems also do not seem to occur in Windows 11 24H2 run via qemu or docker container, though everything runs unusably slowly of course.
I am usually pretty good at troubleshooting linux issues, but this stubbornly refuses to get any better despite rolling forward and backward tons of arch packages, fresh installing Framework officially supported OS’s, etc. Pulling out the hair I do not have over here…
First I want to know if this is affecting anyone else with an intel 13th gen mainboard?
If anyone has any ideas for troubleshooting that I missed, please let me know.
Otherwise I am going to have to pin it on failing hardware and try to RMA out this mainboard, which I would really prefer to not do if I do not actually have to.
Thanks for reading.