[TRACKING] Hard freezing on Fedora 36 with the new 12th gen system

I’m experiencing these issues as well on a fedora 37 12th gen cpu running Gnome (Wayland).
I’ve applied the fixes and I’m still experiencing the crashes. Log reports are identical to what has been submitted earlier. (igpu hanging)

Seriously wondering if this is a Wayland issue atm. A friend of mine using a 12th gen cpu on Fedora (xorg) has not experienced crashing. So I will for the next few days try xorg and report back with my results.

ALSO PLEASE NOTE. My crashing hasn’t been limited to screen freezes although those happen as well. I’ve also experienced issues where my screen will freeze and then ALL applications will shut down all at once as if someone just pressed alt f4 on my whole system. The last time this happened, I noticed there was one app still open even though all other apps were shut down.

That one app was the gnome software store. In addition, like many others here, I’m also experiencing screen freezing when I go into my settings app. I believe that the gnome software store and gnome settings app all have something to do with this and they are the only pattern that I see whenever I face screen freezing or screen crashing.

To conclude, I will let you guys know my results after I switch to xorg. I suspect that I will still experience these issues but who knows. Anybody else who still lurks this forum, if you’ve experienced better results with x11/xorg or better results with a non gnome fedora spin or distro, let me know as well.

From my undestanding everyone has issues on wayland, right?

I have issues on xorg, but I run a more complex system: Qubes OS(fedora 32 in dom0 which has GPU) + kernel 6.1.7-1 + custom xorg config for removing tear issues with it(can be found on the Qubes wiki).

It happens once everyday and basically the screen hangs and then resiezes and it won’t stop until I do a reboot.

I have one of the 12th gen Intel Frameworks running Fedora 37 currently, and the last month or so I’ve been running into various issues around lockups and most recently graphical glitches.

Initially I was running into hard lockups that required me to hold the power button down to restart. That didn’t seem to really be correlated to high CPU usage either. It comes in waves sometimes where it’ll just randomly lock up a ton for a day and then be fine for a few days after. That seems to have stopped for the past week, and now this weekend I’ve noticed graphical glitches (using internal display) and smaller lockups of a second or so.

Anyone else running into similar issues? This has been super frustrating, and for now I’ve switched back to an older laptop that’s been more reliable until I can figure this out.

Yes, a lot of people have similar issues.
https://community.frame.work/t/hard-freezing-on-fedora-36-with-the-new-12th-gen-system/

1 Like

I experience this with both Wayland and Xorg and setting psr=0 has fixed my issue

1 Like

The easiest, most foolproof way would be to swap in another drive (maybe something cheap or secondhand, just to test).

You can install a utility like this:https://linuxconfig.org/obtain-hard-drive-firmware-information-using-linux-and-smartctl

Compare the results you get with whatever the manufacturer says is the latest firmware for that hard drive model to see if you are missing an update.

Hi @BluishHumility

Great news! It is a hard drive issue. Specifically, my hard drive was bent/bowed out towards the keyboard!

All of the symptoms were as others on here had described. Notably, freezes occurred when

  1. I used the laptop off the desk
  2. Alternatively, when I typed hard, especially around the v/c/d/f/x keys (directly over the hard drive).

I purchased a replacement based on the description of others, and was really surprised to see the bowing of the hard drive.

I don’t think it was anything in the Frame.Work design that could have prevented this. I wonder now how many of the other threads where people talk about freezing WD SN850s are related to bowed SSDs.

In case there is a batch issue with WD, this is the relevant information:

  • Model: WDS200T1XOE-OOAFYO
  • Date of Manufacture: January 7, 2022
  • Purchased through: NewEgg

Unfortunately the new hard drive did not stop the freezing issue.

I have tested with all new ram, so at this point am not sure what the issue is. Symptoms suggest a GPU issue (freezes w/ blinking squares, will provide a picture the next time it happens).

Data point: MS Teams in Chrome browser is almost certain to cause a freeze.

Thinking out loud, the issue that was causing the freeze with the mispositioned/bent SSD might have been a short. Repeated shorts may have caused damage to the mainboard.

I appreciate the thought! Which of the outcomes do you anticipate to be more likely due to repeated shorts?

  1. Can’t stay booted
  2. Random, unpredictable restarts
  3. Predictable restarts with certain software loads or hardware use (e.g. heavy typing)

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

2 Likes

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.

2 Likes

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.