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
Appreciate everyone’s updates here.
For me this freezing bug with the black screen only happens if GPU-Hardware-Acceleration is activated. I use an AMD RX 6700 XT with current mesa-git on Manjaro.
This bug also happens in the complete Kernel 6.x Series if Hardware-Acceleration is activated, but it doesn’t happen in Kernel 5.15.x. So Kernel 5.15.x is working fine.
I hope this somehow helps.
That is some legacy LTS kernel action there - assuming Ubuntu?