Trying out kernel 6.1.2 (without i915 patch) as part of Fedora Test Days.. Will report back with how my machine fares, whether it still freezes or not.
2 Likes
What do you call the i915 patch? (seems there are a couple different variants)
By i915 patch I mean the first one posted here by @Aggraxis. Has consistently worked.
In short:
/etc/modprobe.d/i915.conf
options i915 enable_psr=0
sudo dracut --force
reboot
1 Like
Update here from no i915 patch + 6.1.2 kernel land, so far no freezes like before. Been going for about a day now. Plenty of suspends, various activity, and more. Looks promising so far.
Fwiw, I’m testing this (since today) with mesa 22.3.2 and linux 6.1.2 and without
i915.enable_psr=0. I’ll report back.https://gitlab.freedesktop.org/drm/intel/-/issues/6757#note_1707882
Peeps over on the Intel Alder Lake GPU issue tracker are also testing 6.1.2 without the i915 patch.
2 Likes
disabling AV1 seems better but still got crashing with youtube playback on vp9.
i’ve switched to chromium for youtubing and so far no crash. Seems like a firefox specific problem rather than hw related so i’m happy to use that and/or move away from firefox if the problem persists long term. I’ll keep an eye on ff releases.
I brought it up i here due to the chrom* ecode/crashing thats been mentioned thinking its possibly similar but as you’ve sugested, not sure it’s related.
Later today or Monday, I will be putting together some trackable items that will be compiled and shared with Fedora.
Please check back here later, I’ll list them out and ask anyone experiencing issues to share specific details - makes tracking this MUCH easier. 
So later today or Monday, check back here for the details. Thanks everyone.
3 Likes
Interestingly I had a crash while using mpv (and yt-dlp) with hardware accelerated AV1 decoding for playback. So maybe it isn’t Firefox but the VAAPI Driver or ffmpeg maybe.
i think it got it the wrong way around. seems youtube uses vp9 as default, av1 as fallback/low res playback. disabled vp9 and forced av1 but similar issue but seems far less frequent.
i’ve disabled the enforced HW decode in about:config (media.hardware-video-decoding.force-enabled = false, so default FF config) that i was using, but still crashing. i’m trying media.hardware-video-decoding.enabled = false and Settings > Use hardware acceleration when available = unticked tonight to see if it makes any difference to prove if it’s a hw decoder issue or something else.
i dont beleive i’ve done any updates so these should be the only changes i’ve done.
weird that chromium hasn’t had problem if it is a hw decoder issue, but thats what we’re trying to get to the bottom of here . frustratingly the FF abrt crash report is low quality so unable to bug report it to fedora/mozilla or gain any insights myself as to possibilities.
Update here from no i915 patch (enable_psr=0) + kernel 6.1.x land. Over the past couple days kernel 6.1.2 has been rock solid. Minimal to no freezes, great improvement over 6.0.x kernels.
I also tried out 6.1.3 but for some reason hit freezes on it. Doesn’t seem to be any reversions of the i915 fixes that landed in 6.1.2 mentioned in the 6.1.3 changelog so I’m somewhat at a loss as to why the regression in behaviour.
Now that 6.1.4 is out contains various i915 patches (6.1.4 changelog), I’ll be trying it out.
In summary: 6.1.2 seems quite good, 6.1.3 froze quite a bit exhibiting similar behaviour to 6.0.x kernels, and 6.1.4 I’m just starting to test now. Let’s see. 
EDIT: Apparently 6.0.16 onward may also be working fine re: comments below.
2 Likes
Well this is probably it and related to the issue:
So it should be fixed in future kernel(?) and/or firefox update.
Funny enough I have been using 6.0.16 the last 3-4 days on Fedora 37 without the psr_enable=0 fix and it seems fine so far.
Nice! Looks like a bunch of i915 specific patches landed in 6.0.16 as well (changelog). Perhaps the issue only persists through 6.0.15.
1 Like
If you indeed see freezes with 6.1.3, it will be very helpful to report these (with kernel version, mesa version, kernel command line, and logs, if you still have them in the journal) in https://gitlab.freedesktop.org/drm/intel/-/issues/6757#note_1707882.
I’m the one who said over there that I’m currently testing with 6.1.2 and mesa 22.3.2, and (like you), I didn’t see any issues with 6.1.2 so far. But if you see freezes with 6.1.3 again (and IF you’re on a recent mesa?), that would mean that the root cause hasn’t been fixed yet.
1 Like
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:
2 Likes
Fedora Version: 37
CPU: 12th Gen Intel(R) Core™ i7-1260P
kernel: 6.0.17-300.fc37.x86_64
Gnome: 43.2
No i915 fixes active (no enable_psr or otherwise in i915.conf)
Other tunnings: intel_idle.max_cstate=2
1 external monitor via HDMI
1 thunderbolt hub, with 2nd HDMI monitor & 65w USBC PD
Wired Ethernet to laptop (not thru thunderbolt hub)
Sporadic use of Bluetooth head phones
Foreground apps: google_chrome; remmina and 1 RDC session; a few hours of zoom per day.
(out of ordinary) Background app: corporate vpn
This is almost stable rig, w/o the max_cstate, there is 1/3 chance the rig will hang during boot. If get a boot to gdm (w/o max_cstate), it is a time bomb – it will freeze at some point, maybe few minutes maybe hour or two; no correlation to a specific activity or app.
NOTE: not a framework laptop but clevo nv4xPZ
(why do I often get 403’s replying to this forum??)
Mod edit: msg’d you regarding tracking down the 403s)
1 Like
Fedora version: 37
12th gen or 11th gen: 12th Gen Intel(R) Core™ i5-1240P
Kernel version: 6.1.4-200.fc37.x86_64 (built re: Fedora Test Days)
GNOME version: 43.2
Using i915 fixes, if so, which ones: None
Has this been tried yet and if so, any difference: Yes, options i915 enable_psr=0 consistently prevents freezes for me.
Applications running in foreground or background when freeze occurs: Sometimes nothing, sometimes Terminal, sometimes Chrome. Though they seem to clear up after a minute or so of resume from suspend and in that, don’t consistently occur when resuming from suspend.
What if anything is attached: Nothing
Will gladly report over there as I have seen some freezes on 6.1.4 though they don’t persist all that long so far, a few times after resume from suspend, then they clear up it seems. That said, what are you running to capture the logs? I presume it’s not dmesg | grep -i ecode as I’m not seeing anything related return from that.
1 Like
Hm that should work. Maybe try journalctl --dmesg --boot 0 instead of dmesg (or simply journalctl --dmesg to look at all logs; maybe you can still find some ecodes.)
1 Like
Fedora 36 or 37: 36
12th gen or 11th gen: 12th gen
Kernel version: 6.0.18-200.fc36.x86_64 (64-bit)
Gnome version: N/A I’m on KDE
Using i915 fixes, if so, which ones:
options i915 enable_psr=0
options i915 enable_guc=3
options i915 enable_fbc=1
Has this been tried yet and if so, any difference: Nope, it didn’t help at all.
Applications running in foreground or background when freeze occurs: Chrome, usually firefox and discord as well (but Chrome is definitely what’s causing the crash)
What if anything is attached to your Framework; docks, (BT, IR, wired) mouse, keyboard: Sometimes bluetooth headphones, nothing else
As a note, I found several thread on the intel gitlab page that appear to be reporting the same issue. If I understand them correctly, there are a few different applications that can cause it including Chrome.
https://gitlab.freedesktop.org/drm/intel/-/issues/4858
https://gitlab.freedesktop.org/drm/intel/-/issues/7550
1 Like
I’ve had a great time on 6.1.5 and now it’s been pushed out to the masses. Best of luck with your upgrades and subsequent, hopefully, less or complete lack of freezing.
2 Likes
I just want to report that now on Artix (like Arch but without systemd) I don’t need anymore the i915.enable_psr=0 fix.
Previously it was required, in order to avoid severe display issues, like described in this topic.
But since the last Artix update, including among other things a kernel 6.1.4, it works flawlessly without any fix.
Edit: I shall report that today, while skipping forward repeatedly and frequently through a Youtube video, the screen went black and the laptop irresponsive, and I had to restart. I’m not sure it is related to i915.
1 Like
Testing on Fedora 37 with 6.1.5. Will report if I notice anything out of the ordinary.
1 Like