That works (and I’ve been using this forever with i915.enable_psr=0), see upstream docs:
Parameters for modules which are built into the kernel need to be specified on the kernel command line. modprobe looks through the kernel command line (
/proc/cmdline) and collects module parameters when it loads a module, so the kernel command line can be used for loadable modules too.
(The kernel’s command-line parameters — The Linux Kernel documentation)
I fixed the Arch Wiki page.
Framework gpu hangs have been reported in the i915 gitlab. Please refer to those issues and try out the workarounds there:
GPU HANG: ecode 12:0:00000000 Iris Xe XPS 9320 (#6916) · Issues · drm / intel · GitLab
Intel alder Lake GPU hangs on Thinkpad P1 Gen5 (#6757) · Issues · drm / intel · GitLab
i915.enable_guc=2 and i915.enable_psr=0
So after going back to completely stock Fedora 37 Gnome kernel params (and still getting freezing), I tried the method in this post. I’ve now put in about 8 hours of working with the same set of apps, no freezes and no log messages involving a GPU HANG.
I’m tempted to say that did the trick. I will probably give it a few more sessions and then try the same fix on Fedora 37 KDE spin, as using Gnome again made me realize why I like KDE so much 
That’s great to hear! Just so I understand which parts (or all of the parts)?
/etc/modprobe.d/i915.conf
adding:
options i915 enable_psr=0
or adding
options i915 enable_psr=0
options i915 enable_guc=3
options i915 enable_fbc=1
We do suggest
sudo grubby --update-kernel=ALL --args="i915.enable_psr=0"
in the guide, so I’d be interested in getting a better feel for your approach. Thanks!
@Matt_Hartley Maybe the grubby approach would not work if i915 is compiled as a module instead of embedded into the kernel, in which case the modprobe config file would seem to be a good solution.
Or it can also be because i915 is not in the initramfs image? And so it would be loaded later on? I don’t know exactly what the scope of “kernel arguments” is, but that could help us understand the mechanics.
@Matt_Hartley Yes sorry, I should’ve clarified.
I only added options i915 enable_psr=0 to my /etc/modprobe.d/i915.conf
[gabe@macaria ~]$ cat /etc/modprobe.d/i915.conf
options i915 enable_psr=0
The i915.conf file did not exist yet, so I had to create it.
Then I ran
sudo dracut --force
and restarted my machine. I checked journalctl for logs about i915 after the reboot and did see something about a “tainted kernel” but I’m not sure if that was always there or not. Either way, it definitely seems to have done something.
Well, I jinxed it. After about another hour of working, and starting up Obsidian for a few minutes, I get another hard freeze (this time completely unrecoverable).
GPU HANG with a bunch of junk from Obsidian
Mar 09 19:03:59 macaria kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[2068]:d970e timed out (hint:intel_atomic_commit_ready [i915])
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:84dffffb, in obsidian [30394]
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] obsidian[30394] context reset due to GPU hang
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [56:0309/190402.859029:ERROR:shared_context_state.cc(855)] SharedContextState context lost via ARB/EXT_robustness. Reset status = GL_GUILTY_CONTEXT_RESET_KHR
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [56:0309/190402.859670:ERROR:gpu_service_impl.cc(967)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly.
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [13:0309/190402.873685:ERROR:gpu_process_host.cc(975)] GPU process exited unexpectedly: exit_code=8704
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] HuC authenticated
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Mar 09 19:04:02 macaria kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [450:0309/190402.887720:ERROR:angle_platform_impl.cc(43)] Display.cpp:997 (initialize): ANGLE Display::initialize error 12289: glXQueryExtensionsString returned NULL
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: ERR: Display.cpp:997 (initialize): ANGLE Display::initialize error 12289: glXQueryExtensionsString returned NULL
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [450:0309/190402.887799:ERROR:gl_display.cc(508)] EGL Driver message (Critical) eglInitialize: glXQueryExtensionsString returned NULL
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [450:0309/190402.887829:ERROR:gl_display.cc(920)] eglInitialize OpenGL failed with error EGL_NOT_INITIALIZED, trying next display type
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [450:0309/190402.888009:ERROR:angle_platform_impl.cc(43)] Display.cpp:997 (initialize): ANGLE Display::initialize error 12289: glXQueryExtensionsString returned NULL
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: ERR: Display.cpp:997 (initialize): ANGLE Display::initialize error 12289: glXQueryExtensionsString returned NULL
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [450:0309/190402.888031:ERROR:gl_display.cc(508)] EGL Driver message (Critical) eglInitialize: glXQueryExtensionsString returned NULL
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [450:0309/190402.888053:ERROR:gl_display.cc(920)] eglInitialize OpenGLES failed with error EGL_NOT_INITIALIZED
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [450:0309/190402.888087:ERROR:gl_ozone_egl.cc(23)] GLDisplayEGL::Initialize failed.
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [450:0309/190402.889036:ERROR:viz_main_impl.cc(186)] Exiting GPU process due to errors during initialization
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: MESA-LOADER: failed to open iris: /usr/lib/x86_64-linux-gnu/GL/default/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/GL/default/lib/dri, suffix _dri)
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: failed to load driver: iris
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: MESA-LOADER: failed to open zink: /usr/lib/x86_64-linux-gnu/GL/default/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/GL/default/lib/dri, suffix _dri)
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: failed to load driver: zink
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: MESA-LOADER: failed to open kms_swrast: /usr/lib/x86_64-linux-gnu/GL/default/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/GL/default/lib/dri, suffix _dri)
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: failed to load driver: kms_swrast
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: MESA-LOADER: failed to open swrast: /usr/lib/x86_64-linux-gnu/GL/default/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/GL/default/lib/dri, suffix _dri)
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: failed to load swrast driver
Mar 09 19:04:02 macaria md.obsidian.Obsidian.desktop[30342]: [74:0309/190402.922496:ERROR:command_buffer_proxy_impl.cc(128)] ContextResult::kTransientFailure: Failed to send GpuControl.CreateCommandBuffer.
Mar 09 19:04:02 macaria com.discordapp.Discord.desktop[4945]: MESA-LOADER: failed to open iris: /usr/lib/x86_64-linux-gnu/GL/default/lib/dri/iris_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/GL/default/lib/dri, suffix _dri)
Mar 09 19:04:02 macaria com.discordapp.Discord.desktop[4945]: failed to load driver: iris
Mar 09 19:04:02 macaria com.discordapp.Discord.desktop[4945]: MESA-LOADER: failed to open zink: /usr/lib/x86_64-linux-gnu/GL/default/lib/dri/zink_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/GL/default/lib/dri, suffix _dri)
Mar 09 19:04:02 macaria com.discordapp.Discord.desktop[4945]: failed to load driver: zink
Mar 09 19:04:02 macaria com.discordapp.Discord.desktop[4945]: MESA-LOADER: failed to open kms_swrast: /usr/lib/x86_64-linux-gnu/GL/default/lib/dri/kms_swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/GL/default/lib/dri, suffix _dri)
Mar 09 19:04:02 macaria com.discordapp.Discord.desktop[4945]: failed to load driver: kms_swrast
Mar 09 19:04:02 macaria com.discordapp.Discord.desktop[4945]: MESA-LOADER: failed to open swrast: /usr/lib/x86_64-linux-gnu/GL/default/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory (search paths /usr/lib/x86_64-linux-gnu/GL/default/lib/dri, suffix _dri)
Mar 09 19:04:02 macaria com.discordapp.Discord.desktop[4945]: failed to load swrast driver
Maybe I try Ubuntu…
This is definitely one option. I’ve used Obsidian successfully on Ubuntu.
While still on Fedora, with Obsidian open, do you have other Chromium based applications or browsers open by chance?
@Matt_Hartley Nope, all I had open was the apps I mentioned here plus Obsidian.
As an update, I added i915.enable_dc=0 to my grub kernel params with the following command:
sudo grubby --update-kernel=ALL --args="i915.enable_dc=0"
and I haven’t experienced any freezes since, with some heavy NoMachine usage with Obsidian open, as well as streaming a movie using Google Chrome. Still no idea if this has solved the issue but it’s at least looking good.
Sounds good, appreciate the update. I will leave this open as tracking so we can see if this reoccurs.
I haven’t read this discussion in a while, but I have to say that now I experience hard freezing on both Wayland and Xorg on multiple DE’s(Gnome, XFCE, KDE) and multiple distros(fedora,gentoo and I don’t remember and if on Arch).
I think it started to happen and other combination(than Gnome + Wayland) after a kernel update about two months ago(I can confirm it is Linux only, as I didn’t have such issues on BSD).
However, what I can say for sure that each time it starts it will happen when I have firefox open, and that it behaves in three different ways:
Everyone who is experiencing freezing, please reply with this outline below so I can get this into a spreadsheet and track this down for the folks at Fedora. Please use this format. Thanks!
Fedora 36 or 37:
12th gen or 11th gen:
Kernel version:
Gnome version:
Using i915 fixes, if so, which ones:
Has this been tried yet and if so, any difference:
Applications running in foreground or background when freeze occurs:
What if anything is attached to your Framework; docks, (BT, IR, wired) mouse, keyboard:
To answer to my own comment:
no I was wrong, the grubby approach, as any kernel argument, works as well for built-in modules as for loadable modules, so there is no problem.
Source: https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html
Fedora 36 or 37: 37
12th gen or 11th gen: 12th gen
Kernel version: 6 (I forget which exact version, but it was across multiple versions)
Gnome version: 43
Using i915 fixes, if so, which ones: tried just psr=0 in grub kernel args, just enable_psr=0 in /etc/modprobe.d/i915.conf, and tried that one with i915.enable_dc=0 in grub kernel args
Has this been tried yet and if so, any difference: Yes, and no real difference (still got crashes, frequency didn’t seem to really change much)
Applications running in foreground or background when freeze occurs: A wine Windows game (Corporate Clash) which is where the GPU HANG was reported, Firefox, Obsidian (has also been reported for the GPU HANG but less frequently), NoMachine (as a client), Telegram, Discord (not always running).
What if anything is attached to your Framework; docks, (BT, IR, wired) mouse, keyboard: Nothing attached.
Just gave Kubuntu 22.10 a spin. It went great for a few hours but inevitably still got a GPU HANG with the same i915 async fence message on my wine game. I don’t think stock Ubuntu is gonna fare any better to be completely honest, this is clearly an issue with the graphics driver in Linux interacting with the Intel 12th gen GPU. I know that’s not a very scientific claim but I just cannot imagine how Ubtuntu stock could be doing something that would fix this issue that has appeared across every popular DE and distro.
My last hope before just installing windows for now is trying a rolling release distro (Tumbleweed, as I’m quite familiar with OpenSUSE), maybe something has been fixed in bleeding edge kernel.
This could be a relevant thread about my experience GPU HANG: ecode 9:1:85dffffb while using PCSX2, Minecraft and probably MANY other OpenGL applications (#4858) · Issues · drm / intel · GitLab
Are you trying all of them at once or one a at a time? Ideally, psr=0 in grub should resolve the issue. I’m on Fedora 37 right now.
This may be the issue. Run this with a visible journalctl -f running to see if it captures anything as it crashes.
Yeah I kind of said it in a confusing way. I tried just psr=0, then removed that and tried the i915 conf change, then kept the conf change and added the enable_dc=0, none worked.
And yes, I think it has something to do with the apps I’m running, be it with OpenGL (would make sense for wine) or electron (which I think Obsidian uses).
Either way, I kinda require being able to use those apps without crashing, and it looks like this issue is beyond me to solve with tweaks. Still hoping rolling Linux will help, but my hopes are low.
Btw thanks for all your help with trying to resolve these issues. I’m convinced this problem has nothing to do with Framework hardware, but you’re still out here replying all the same
I suggest to run wine in the terminal and log its output (both stdout ans stderr) to a file.
Do the same with journalctl as Matt suggested.
Then attach those files here.
Hi there, just a quick question. What is the side effect of psr=0? Does it increase battery use? Decreased performance? Or lead to any other issues? Is this still necessary as of March 2023 or do new kernels remove the need? Thanks!
It disables Panel Self Refresh, so every frame is transferred by CPU, even if the frame was not actually changed (think about static image). This prevents CPU from entering C10 power state, thus increasing overall power consumption.
Latest Linux kernels typically work fine with PSR, so if it works for you then I recommend keeping it on, to save power and increase battery life.