I appreciate the thought! Which of the outcomes do you anticipate to be more likely due to repeated shorts?
When I’ve had shorts previously I couldn’t boot, but hardware isn’t an area I’m deep in.
Same problem.
i5-1240P
Samsung MZ-V8V1T0BW (nvme, 1tb)
2x Crucial CT16G4SFRA32A (default RAM)
Manjaro KDE
thanks for the input vbakc.
Yeah, every OS, hardware bit I threw at it now freezes like crazy. Best guess is issue with the battery system since I tried all different hardware (including a new mainboard, RAM, hard drive) and four different operating systems (including Windows 10 pro and Windows 11 pro, Ubuntu, Fedora).
Any update on this? I don’t know if I’m having the same issue or just something similar, but occasionally my screen will freeze, requiring a reboot. Any playing video/audio keeps playing as normal, but the screen is static (although no artifacting, etc.) I will note that whenever I first boot up and log in, there is a row of pixels on the top of the screen that flicker (typically blue) for a few seconds, and the screen may temporarily freeze for a few seconds, but usually within 15 seconds of boot and login everything works. The issue generally arises after waking from suspend which is usually when a hard reboot is needed. Can’t tell if this is a Wayland issue or a suspend issue or a hardware issue.
OS: Fedora 37, no LUKS, fairly stock install
Framework: 1240p + WD SN770 + 32GB 3200 + 4x USB C
I highly recommend you look at these threads Hard freezing on Fedora 36 with the new 12th gen system , Fedora Freezes and Flickering on newer Kernels , and Linux freezing on multiple distros as well as this one about the 3.06 BIOS update 12th Gen Intel Core BIOS 3.06 Beta .
Merging this with the appropriate thread as not to have so much duplication.
All, if you’re still having freezing issues:
sudo grubby --update-kernel=ALL --args="psr=0"
or
sudo grubby --update-kernel=ALL --args="i915.enable_psr=0"
Differences between the two at this link.
Don’t forget a reboot to make these changes active!
If you did this, verify your grub entries and make sure you have it added.
Fedora 37 kernel 6.1.9-200 has had no freezing whatsoever. Tested on two separate 12th gen systems.
if yours still is:
Update.
Post your /etc/default/grub
cat /etc/default/grub
nvme.noacpi=1 and psr=0 are my only entries.
Unattached all hubs, displays, try again and report back.
Please do not post “still freezing” or other unhelpful comments. We need details as to what is running in the background (no matter how unassuming)
As I too, found this resolved a freezing issue recently, it’s been added to the Fedora guide.
Thank you
Dont forget a reboot to make these changes active!
While my freezing IS fixed with psr=0, is that the correct command? I’ve got this following line in my notes from November (and mentioned around that time in this thread), and is the one i’m using. Is it different, or is one an alias of the other so effectively the same?:
sudo grubby --update-kernel=ALL --args="i915.enable_psr=0".
…And just incase anyone would like to revert this change back to default (psr=1): sudo grubby --update-kernel=ALL --remove-args="i915.enable_psr=0"
Ack! Fixed.
One of essentially a more generic form of the other. I tested the one I posted, but yes, if someone wishes to have the less generic version, i915.enable_psr=0 works as well.
In my testing, the suggestion I made works, but ideally, either should accomplish the same with the graphics on 12th gen.
TLTR, psr=0 is usually less heavy handed.
GPU Hangups and hard freezing are very common (~10 minutes to 1 hour interval) and persisting with Kernel 6.1.9-200.fc37.x86_64.
All defined boot options in /etc/default/grub:
/etc/default/grub (edited to remove UUIDs)
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.luks.uuid=<> rhgb quiet module_blacklist=hid_sensor_hub psr=0"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
Options have been verified to be applied in boot during testing
Special install functionality
LUKS encryption on root volume
BTRFS root partition
Wayland with XWayland support
Installed hardware:
SSD: Samsung 980 PRO 1TB
Memory: G.Skill F4-3200C22D-16GRS (2x8GB 3200MHz CL22-22-22-52 1.20v DDR4 SODIMMs)
CPU config: i5 1240p
Actively running applications:
(Core minimal KDE Plasma installation)
Dolphin
Firefox
Android Studio
kvm-accelerated QEMU (Android x86 virtualization under IntelliJ IDEA/Android Studio)
Yakuake
Specific hang and notable subsequent log entries beside XWayland and applications sometimes crashing due to lost signal
Asynchronous wait on fence 0000:00:02.0:kwin_wayland[2021]:16d8e timed out (hint:intel_atomic_commit_ready [i915])
i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
i915 0000:00:02.0: [drm] HuC authenticated
i915 0000:00:02.0: [drm] GuC submission enabled
i915 0000:00:02.0: [drm] GuC SLPC enabled
followed by constant
kwin_wayland[pid]: kwin_core: precision lost! floating value sent to X ##.##
and sometimes full kwin_wayland context resets followed by a hard freeze.
After having read through the whole thread I am still confused which kernel parameters might fix the problem (at least as a workaround). I found these possibilities on the Internet:
i915.enable_dc=0
i915.enable_psr=0
i915.enable_guc=0
Some people claim that enable_psr=0 solved the problem, while enable_guc=0 is mentioned in the Arch wiki.
I don’t want to blindly apply all of them since they disable features which are there for a good reason.
So, which one should I try first?
Fortunately the GPU freeze occurred only twice last week. The laptop is fairly new (bought/installed it 3 weeks ago, no problems in the first two weeks and then two freezes last week). The consequences were unpleasant: kwin_core crashed and I had to kill Xorg from a tty.
BTW - it is a i1240p.
We are recommending psr=0 Fedora proper (Gnome). KDE, etc, you’ll need to do your own testing.
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.
It is and as I type this on Fedora 37, it’s a part of the bleeding edge distro experience. 
Snapshots are always there for us. Working with Btrfs - Snapshots - Fedora Magazine
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.
Why should this freezing problem be specific to Fedora? There are reports from different Distros, e.g. Ubuntu.
BTW - I am using Arch. I found this thread as I was looking for a solution.
Yes, point of origin. However, we’re getting them from Fedora in this instance (distributor).
Per my contact on the Fedora team, this has effective other distros as well. However, we have seen this heavily on Fedora.
My Fedora 37 layout and experiences, for comparison.
BTW, this is great to hear.
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.
My /etc/default/grub:
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-135437e1-b6e7-44ae-b9b4-fc2990c4adae rhgb quiet module_blacklist=hid_sensor_hub psr=0"
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
The logs surrounding the last freeze:
Feb 18 13:49:36 macaria kernel: Asynchronous wait on fence 0000:00:02.0:kwin_wayland[2493]:43f06 timed out (hint:intel_atomic_commit_ready [i915])
Feb 18 13:49:40 macaria touchegg[2967]: Error connecting to Touchégg daemon: Could not connect: Connection refused
Feb 18 13:49:40 macaria touchegg[2967]: Reconnecting in 5 seconds...
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:84dffffb, in CorporateClash. [15795]
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] CorporateClash.[15795] context reset due to GPU hang
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] HuC authenticated
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Feb 18 13:49:41 macaria kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Feb 18 13:49:41 macaria kwin_wayland[2493]: kwin_scene_opengl: A graphics reset not attributable to the current GL context occurred.