Mine has been behaving since the last time I checked in. I spent a solid workday teleworking over VMware Horizon, and it handled all of that H264 decoding just fine. I even paired a Keychron K2 and my Bluetooth ear buds… streamed music all day and banged out some YAML. No issues or freezes.
I will say, having followed some of the side discussions in this thread, that the Xorg/Wayland thing was a rabbit hole that I jumped down. What I found during my testing with a few different games at the time was that Xorg, while a little more stable, was not anywhere near as responsive or snappy as the Wayland session. I was able to reproduce crashes under both of them (F36, before I upgraded). This was also in both KDE Plasma and Gnome. I’ve had it crash in both desktop environments just by messing with each respective settings app.
The only thing that has consistently provided relieve from the crashes is the kernel option for the i915 module. I’ve also been seeing the same kind of feedback from folks who own 12th gen Intel laptops from other brands (Lenovo specifically). We even had a kernel regression at one point where they broke us and we had to wait for another update before i915.enable_psr=0 took effect again. I’m pretty sure this isn’t Fedora-specific or desktop environment-specific. It’s definitely not manufacturer-specific.
i’m with aggraxis on this; the fixes have all been coming from upstream kernel/mesa packages and not specific to Fedora. Thankfully due to Fedora’s ethos, these fixes have come frequently and i’ve had the same experiences as Matt_Hartley; 1240p, fully upto date Fedora37 KDEspin… psr=0 fixes it and it’s rock solid.
I’d rather have working PSR too, but stability > whatever battery life improvements PSR brings.
I’m getting hard freezes with similar scenario to @JHeffron
KDE Fedora 37, Linux 6.1.9, default KDE Wayland
12th gen Framework with a 500GB Samsung SSD
This happens so far when playing a low-intensity game (Corporate Clash) via WINE. Other than when playing games, it doesn’t happen, which is much better than my experience with Fedora Gnome, which incurred freezes like this all the time, doing basically nothing.
@nadb Oh you can ignore touchegg, I had it installed cause I was testing X11 session to see if it behaved better, and I guess I didn’t fully disable its backend before starting this Wayland session. I got the exact same crash before installing touchegg, so I highly doubt that’s part of the problem.
I got that error over and over for the entire couple hours prior to the crash in the log. The timing just looks suspicious
Had this issue on Debian Bookworm, specifically when using Gnome Settings. I added psr=0 to GRUB_CMDLINE_LINUX_DEFAULT at /etc/default/grub then sudo update-grub and I haven’t experienced hard freezes ever since.
Just got the same crash in X11. This honestly is kind of a showstopper bug for me. Might have to switch to using Windows on this thing (I’ve tried Fedora Gnome and it was much worse than KDE, and I doubt changing distros is gonna fix anything, it’s the same underlying stuff)
Logs:
Feb 18 23:06:15 macaria kernel: Asynchronous wait on fence 0000:00:02.0:kwin_x11[2193]:b0f72 timed out (hint:intel_atomic_commit_ready [i915])
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:84dffffb, in CorporateClash. [16280]
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] CorporateClash.[16280] context reset due to GPU hang
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] HuC authenticated
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Feb 18 23:06:18 macaria kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Feb 18 23:06:18 macaria ksmserver[2986]: Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: VA-API test failed: failed to initialise VAAPI connection. (t=0.521279) |[1][GFX>
Feb 18 23:06:18 macaria kwin_x11[2193]: kwin_scene_opengl: A graphics reset not attributable to the current GL context occurred.
Feb 18 23:06:18 macaria kwin_x11[2193]: OpenGL vendor string: Intel
Feb 18 23:06:18 macaria kwin_x11[2193]: OpenGL renderer string: Mesa Intel(R) Graphics (ADL GT2)
Feb 18 23:06:18 macaria kwin_x11[2193]: OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.3.5
Feb 18 23:06:18 macaria kwin_x11[2193]: OpenGL shading language version string: 4.60
Feb 18 23:06:18 macaria kwin_x11[2193]: Driver: Intel
Feb 18 23:06:18 macaria kwin_x11[2193]: GPU class: Unknown
Feb 18 23:06:18 macaria kwin_x11[2193]: OpenGL version: 4.6
Feb 18 23:06:18 macaria kwin_x11[2193]: GLSL version: 4.60
Feb 18 23:06:18 macaria kwin_x11[2193]: Mesa version: 22.3.5
Feb 18 23:06:18 macaria kwin_x11[2193]: X server version: 1.20.14
Feb 18 23:06:18 macaria kwin_x11[2193]: Linux kernel version: 6.1.11
Feb 18 23:06:18 macaria kwin_x11[2193]: Requires strict binding: yes
Feb 18 23:06:18 macaria kwin_x11[2193]: GLSL shaders: yes
Feb 18 23:06:18 macaria kwin_x11[2193]: Texture NPOT support: yes
Feb 18 23:06:18 macaria kwin_x11[2193]: Virtual Machine: no
Feb 18 23:06:29 macaria kernel: Asynchronous wait on fence 0000:00:02.0:Xorg[1490]:62374a timed out (hint:intel_atomic_commit_ready [i915])
I can try that next just to try to troubleshoot this bug before I jump ship to Windows… I’m not sure what that would do here, though. Wouldn’t that only affect graphics while booting?
Edit: I’ve decided to give Fedora Gnome another try, now that the psr=0 tweak is so official. If I still get crashes of a similar nature, I can only assume it’s a bug in the Intel graphics drivers (a bug which appears to have maybe been seen in posts through out the last 5 years, which is perplexing)
This issue used to occur to me almost every 30min to an hour. I noticed that almost all the time I would face GPU hangs on the newest kernel and Mesa were related to gnome-control-center in journalctl. I found that switching from Gnome to Hyprland has resolved all issues for me (it has been about 2 weeks of heavy usage with no GPU hangs). Maybe, Hyprland just isn’t triggering the issue in the same way Gnome and KDE are? In case this info is useful for yall, here are my kernel info and mesa version:
This. This if the first thing to try. Then if that doesn’t let us know. I’d lose the additional parameters for testing unless they came provide by default.
Yeah, all the crashes I’ve posted about have been on Fedora 37. Granted, it was all under the KDE spin, so maybe this is somehow a problem with KDE’s window manager… Stinks cuz I much prefer KDE. But I can live with Gnome over Windows
Getting some hangs that last 2-5 seconds, with these logs:
Feb 24 21:19:03 macaria kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[1899]:46dfe timed out (hint:intel_atomic_commit_ready [i915])
Feb 24 21:19:07 macaria kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
Feb 24 21:19:07 macaria kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Feb 24 21:19:07 macaria kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
Feb 24 21:19:07 macaria kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
Feb 24 21:19:07 macaria kernel: i915 0000:00:02.0: [drm] HuC authenticated
Feb 24 21:19:07 macaria kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Feb 24 21:19:07 macaria kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Some of them don’t include the i915 message, but they all show GPU HANG. I wasn’t even playing any games this time, just running apps and streaming a remote desktop. Something’s definitely still up.
