What issue exactly are you referring to that should be fixed upstream? As far as I know, there are still open bug reports relating to i915 freezes
OpenSUSE TW KDE (no kernel modifications) update:
Haven’t had any i915 problems so far, using all the same apps. I have, however had kwin resets where I get a short freeze (1-2 seconds) and then all my windows are gone. The journalctl log messages are seemingly non-existent, just something about kwin_wayland dumping core and then complaining that wayland seems to have died.
I think OpenSUSE just isn’t great for laptops so I will go ahead and try the Fedora 38 Beta, but yeah it seems maybe something in the latest kernel actually might have improved the i915 GPU HANG situation. I’ll see how Fedora goes 
After about an hour of stress testing the same apps on Fedora 38 Beta (no kernel boot command modifications), already got a GPU HANG from i915 (hint:intel_atomic_commit_ready), same as usual. However, this time, after about 10 seconds it actually recovered! Didn’t have to restart my laptop.
One thing I will note is that during the hour without problems I was using the balanced power profile, and I got the hang like 10 minutes after setting it to the performance profile. That really makes me think of this report
so I’m going to try its solution out and see how it goes.
1 Like
I’m not seeing any badness yet since upgrading to F38b and taking out the kernel module parameters. Will try more crazy things to see if I can blow it up.
2 Likes
Please keep updating. Thus far, so good! 
A post was merged into an existing topic: [SOLVED] Ubuntu 22.04.2 with Kernel 5.19 => fan noise issues at low load
- Pop! OS 22.04
- #202303130630~1681329778~22.04~d824cd4 SMP PREEMPT_DYNAMIC Wed A
- nope, stock
- WD_BLACK™ SN850X NVMe
- Web browsing (Brave) or using Obsidian.
been using F38 KDE with removed psr=0 since it went final last week; so far all good. Plenty of media playback from various sources without issue.
1 Like
Across the board, seems like 38 has been stellar. I’m very happy with it.
1 Like
Hi, I’ve just experienced some occasional freezes and jitters on F38 (kernel 6.2.15-300.fc38.x86_64) with my 12th gen Framework - so it doesn’t appear to have gone away just yet.
psr=0 does seem to have eliminated them so far, though.
1 Like
Bringing in @Loell_Framework to this conversation.
@snoopdouglas You indicated that the kernel parameter psr=0 seems to be helping. Is this 11th or 12th gen Framework 13?
1 Like
hi @snoopdouglas ,
will try and check this on a 11th and 12th gen with F38 and see how psr=0 parameter goes.
2 Likes
@Loell_Framework - 12th gen as I said in my previous post. I had an 11th gen mainboard before, and should note that I only started experiencing jitters/freezes after the upgrade. dmesg output is consistent with the bug reports on the DRI issue.
(Edited as Loell is handling this - Matt)
1 Like
@Loell_Framework Kernel 6.3.4-201.fc38.x86_64 has just been released; I’m now using that without psr=0 and the symptoms appear to have disappeared, having used it for ~24h. Will update if they reappear.
Long term update: I maybe I had some freeze issues related to psr=0 and maybe even intel_idle settings; but things turned out different for me.
Not a framework laptop, but one with 12th Gen Intel(R) Core™ i7-1260P, but very similar symptoms as noted in this thread. Laptop started with fedora 37 and jumped ship to fedora 38 – terrible freezing and outright total crashes for months!
I am currently 100% fixed, with nearly 2 weeks of absolutely no problems and NO kernel boot parameters. Using all features of laptop – thunderbolt/usb-c hub with PDS, bluetooth, driving 2 monitors, USB A keyboard, USB A wireless mouse, usb ethernet and/or wifi, webcam too. Everything is just working.
FWIW current kernel: 6.2.15-300.fc38.x86_64.
What was the problem? Well I am certain there was some kernel driver issues related to the 12th Gen intel stuff, early on. I feel those were probably addressed a while back, probably with advent of Fedora 38. After a particular knarly crash and spying some log artifacts that said something about ‘memory’, I ran a memory test (memtest86+) several times – all were very very negative. A pair of new DIMMs later and many positive memtest86+ runs, everything has been great!
YMMV – but this thread has been a valuable resource for me during this effort.
2 Likes
Thank you for sharing a valuable insight @Fred_Welland , especially taking note on kernel 6.2.15-300.fc38.x86_64. 
Out of curiosity how long did you run each of those memtest86+ runs? I’ve been suffering from what seems like the symptoms in this thread (12th gen + Linux Mint) to the point that my Framework laptop is unusable (~50% crash rate within 5 minutes, ~90% within 30 minutes). But for me a memtest run overnight did not detect a memory issue.
After ~3 weeks of not using my laptop at all (due to the freezing) I just upgraded all the packages and I’m now running kernel 6.2.16-060216-generic x86_64. Hopefully the crash will be gone now
The negatve tests were pretty quick to go negative. I’d say within 1 or 2 minutes of starting the memtest86+ basic run I would start getting failures. That pattern was repeatable; I probably did 6 runs all negative before concluding I had a bad dim or dims. Each run, when I let it complete was maybe like 10 mins before completion with summary report.
The economics were such that
I replaced the 2x8 pair with 2x16 pair.
Those (positive ) runs did seem to take longer but didnt seem like 2x the 16gb runs (perhaps error reporting slowed things down??) ; so maybe like 15 mins or so.
I probably did 6 or 8 of those success runs; beforeconcluding the mem issue was whipped.
I then just dove into full on testing with f38. I have had no crashes since (and few days before; I delayed my posting to ensure my issue was addressed) that time.
HtH
Note i never did any of more advanced test runs offered by mt86+. Also maybe 4 weeks prior i did run a user space memchecker that i googled up. That ran clean. There is some www noise about effectiveness of that tool. I actualy dont recall the name.
Thanks for the additional information! Unfortunately I’m still getting crashes, I’ll try running memtest again, although my suspicion is that something else is causing the issue for me.
@Jason_Axelson, for me I think I’ve isolated the issue to a USB-C multiport HUB 49140, which I use for my 2nd monitor and to charge the laptop itself:
Manufacturer: LENOVO
Product Name: 21E30086BM
Version: ThinkPad E14 Gen
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 12
On-line CPU(s) list: 0-11
Vendor ID: GenuineIntel
Model name: 12th Gen Intel(R) Core™ i5-1235U
CPU family: 6
Model: 154