Thank you! I just ran it and got the following output:
[72899.691144] i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:859ffffb, in chrome [65524]
[72899.793255] i915 0000:00:02.0: [drm] chrome[65524] context reset due to GPU hang
I should note that I got a soft freeze earlier today though. The computer froze temporarily, but unfroze itself while I was pressing the power button (so it never actually turned off). I think I ran that correctly this morning when I got nothing back. Again, I can’t actually run the command when the hard freeze issue happens as my computer ends up completely frozen and unresponsive, so I have no option other than to restart it.
Already on Fedora 37 myself. Had two hard freezes in one week. Both times it appeared to be related to 1) coming out of sleep following an extended screen lock, and 2) bluetooth mouse had just connected again and almost immediately a hard freeze. I have disabled suspend, sleep, hybrid-sleep, and hibernate by way of a custom sleep.conf for systemd. I don’t use them to begin with, so hopefully this takes care of my freezes. Other than the two hard freezes no glitches…except of course the usual weirdness with docks.
I have not had a chance to try any of the steps listed in this thread yet, but I saw there were some questions about whether anyone had tried Ubuntu yet. I have been having this happen intermittently for the last couple weeks.
Fedora 36 has seen a few kernel updates of late and other updates and I’m wondering if freezing is still going happening for people? At least on the latest kernel and updates.
My experience seems to have been improved. I am on kernel 6.08, recent Framework w/ i5-1240P
I did experience lockups , sometimes in clusters relatively close together, but have been trying some of the recommendations in this thread and they reduced in frequency.
As of now, I’ve been up for over 48 hours running like a charm.
I have been staying away from Settings and not leaving it running in the background. Not sure it helps but most my freezes were in Gnome Settings or Gnome Software, or where they where left running in the background. I’ve definitely seen “I was in settings” mentioned in may of the freeze experiences here.
Anyway, I will try using Settings more today after avoiding it to see if freezes return.
just upgraded F36 (KDE) from 6.0.5, to 6.0.8 (and whatever other packages i had outstanding), removed the psr line with sudo grubby --update-kernel=ALL --remove-args="i915.enable_psr=0" and while i havent seen anything bad in dmesg, it is blocking me from unlocking the laptop. specifically wake laptop up, enter passwd/fingerprint click the ‘unlock’ button… nothing. acts like i haven’t clicked it.
re-applying sudo grubby --update-kernel=ALL --args="i915.enable_psr=0", reboot, login, sleep and wakeup does not exhibit this problem.
My 12th gen board is installed, Fedora 37 installed as well. Going to spend some time trying to replicate this. I’m also following this thread as well.
Going to leave GNOME Software open for an hour, see if I can replicate any of this.
also
@nadb Docks and Bluetooth will be a challenge I suspect. For now (as was stated above I believe) btusb.enable_autosuspend=0 is one option.
@Matt_Hartley I have not run into the hard freeze since updating to kernel 6.0.7. Now on 6.0.8. I am beginning to suspect the power delivery issue is actually something to do with the way Thunderbolt 4 handles it, or rather it is not recognizing it properly. There has been commentary elsewhere that a thunderbolt 4 cable might fix it, but I am planning on upgrading anyway, so not really a big deal. Just annoying, and in this case probably not a Framework firmware issue.
The lockups is very random, I think, so it’s quite hard to replicate. I used to experience it without i915.enable_psr=0. With this kernel param, there’s no more lockups for normal usages, but it still freezes when I share my screen on a video call.
i’d just like to add that the issue isn’t framework specific. that ‘GPU BUG: 0:12:0.0000’ or whatever it is across a number of manufacturers like acer and lenovo hardware.
i’ve upgraded to F37 last night (after my last post) too.
In the time i’ve been using it (1-2weeks) i havent found any negative concequences with psr=0. I havent looked into what could occur or even what its purpose is so i’m happy enough to keep running it long term.
I took a quick glance and a page search of psr and i915 on the kernel.org changelog pages, but couldnt see anything since 6.0.5 to indicate any psr or i915 related freezing issues have been worked upon.
Just an update on what I’ve been seeing. I had a hard freeze seemingly at random earlier today and then another just now while I was playing the tower swap browser game on chrome, so I think maybe the game itself can independently cause freezes for me. I’m confident that this game wasn’t triggering freezes when I was still using fedora 35 since I was playing it for upwards of several hours at a time without any issues.
If anyone else wants to try to replicate, I’m using chrome version Version 107.0.5304.110 (Official Build) (64-bit), the game can be found here: Tower Swap, and my system information is below (copied from the page in KDE settings).
Operating System: Fedora Linux 36
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.99.0
Qt Version: 5.15.6
Kernel Version: 6.0.8-200.fc36.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 16 × 12th Gen Intel® Core™ i5-1240P
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Graphics
Manufacturer: Framework
Product Name: Laptop (12th Gen Intel Core)
System Version: A4
Does anyone know of a way to prevent or reduce these freezes? They’ve become much more frequent for me since updating to fedora 36. I’ve had 2 soft freezes (laptop unfroze itself after a bit) and 2 hard freezes (I had to restart the laptop) happen completely at random just today. I think I’ve had more random freezes in the week since I updated to fedora 36 than in ~2 months when I was using fedora 35.
EDIT to add additional information. I found a reddit thread that recommended checking the kernal log using the following command.
When I ran the command, there was a section with timestamps that match when my laptop most recently froze that look like they might be related to the freeze. I don’t have experience with these logs, so I’m not sure if the “stopped heartbeat” is actually the freeze. If it is the freeze, is there any way to fix that?
Nov 16 22:02:47 fedora kernel: Asynchronous wait on fence 0000:00:02.0:kwin_wayland[1873]:ac680 timed out (hint:intel_atomic_commit_ready [i915])
Nov 16 22:02:51 fedora kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:859ffffb, in chrome [20329]
Nov 16 22:02:51 fedora kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Nov 16 22:02:51 fedora kernel: i915 0000:00:02.0: [drm] chrome[20329] context reset due to GPU hang
Nov 16 22:02:51 fedora kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
Nov 16 22:02:51 fedora kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
Nov 16 22:02:51 fedora kernel: i915 0000:00:02.0: [drm] HuC authenticated
Nov 16 22:02:51 fedora kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Nov 16 22:02:51 fedora kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
@Nicholas_La_Roux@Matt_Hartley Yes, Aggraxis’s fix was the first thing I tried and unfortunately it did not work for me. Do you know of any other possible solutions?
We’ve reached out to a contact at Fedora today, we’ll keep at this.
I’m testing a video loop right now (long one), with Fedora 37 GNOME Settings open. Also this is the latest kernel in play as well for Fedora 37, 6.0.8.300.
something i’ve picked up in this thread is different GPU BUG entries in dmesg from various people.
admittedly at this point in time i have no idea what the ecode actually represents but appears that those encountering the specific GPU HANG: ecode 12:0:00000000 in dmesg appear to be fixable by i915.enable_psr=0 method.
backscrolling through this thread i can see a few other different ecodes where psr=0 isnt fixing it for them so maybe there’s multiple or unrelated issues here?
Hate to say it but Extensions have been known to contribute to grpahics issues since the beginning of Gnome 3. In other words give it a try with Extensions off, or at least only the ones installed by default, and see if there are any improvements. Another thing I am curious about is if the people experiencing additional issues are on Wayland or Xorg.
Both of these are absolutely fair and correct points. When in doubt, always disable extensions (extra ones installed at least) and then try Xorg as an alternative for testing.