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

Same symptoms here: opening the Settings app, then navigating to Keyboard → View and customize shortcuts froze graphics and input twice in a row. Not even SysRq + REISUB worked. Sound, on the other hand, kept going.

Machine: i7-1260p with SN850
OS: Arch with GNOME

First log:

Aug 21 19:18:52 laptop gnome-character[2027]: JS LOG: Characters Application exiting
Aug 21 19:18:59 laptop kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[1436]:252 timed out (hint:intel_atomic_commit_ready [i915])
Aug 21 19:19:01 laptop kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:0020fffe, in gnome-control-c [2189]
Aug 21 19:19:01 laptop kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0

Second log:

Aug 21 19:17:24 laptop gnome-character[7651]: JS LOG: Characters Application exiting
Aug 21 19:17:32 laptop kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[1647]:ec2a timed out (hint:intel_atomic_commit_ready [i915])
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:0020fffe, in gnome-control-c [7764]
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] gnome-control-c[7764] context reset due to GPU hang
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] HuC authenticated
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Aug 21 19:17:35 laptop kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Aug 21 19:17:53 laptop systemd-logind[872]: Power key pressed short.

@arredoluis as this doesn’t seem specific to Fedora, what do you think of editing the subject? Might give it more visibility.

Something I noticed which might or might not be related: if I boot the machine, bring up the BIOS, and do nothing for a couple of minutes, fan and temperature increase constantly. Does anyone else experience this?

2 Likes

Yes, I experience this as well. I actually can be ‘doing things’ in the BIOS menus and it still happens. Basically, any powered on state that isn’t booted into an OS, it seems to happen. Think I’ve seen others mention this elsewhere as well…

I am. My mesa version is 22.1.6-1 and my kernel is 5.19.1-3.

@M4X what’s the output of

$ lspci -k | grep -A3 VGA
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c)
	Subsystem: Device f111:0002
	Kernel driver in use: i915
	Kernel modules: i915

and

$ inxi -G
Graphics:
  Device-1: Intel Alder Lake-P Integrated Graphics driver: i915 v: kernel
  Device-2: Realtek Laptop Camera type: USB driver: uvcvideo
  Display: x11 server: X.Org v: 21.1.4 with: Xwayland v: 22.1.3 driver: X:
    loaded: modesetting gpu: i915 resolution: 2256x1504~60Hz
  OpenGL: renderer: Mesa Intel Graphics (ADL GT2) v: 4.6 Mesa 22.1.6

@Eddie_Zaneski

~$ lspci -k | grep -A3 VGA
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-P Integrated Graphics Controller (rev 0c)
	Subsystem: Device f111:0002
	Kernel driver in use: i915
	Kernel modules: i915
~$ inxi -G
Graphics:
  Device-1: Intel Alder Lake-P Integrated Graphics driver: i915 v: kernel
  Display: wayland server: X.Org v: 22.1.3 with: Xwayland v: 22.1.3
    compositor: gnome-shell v: 42.4 driver: X: loaded: intel
    unloaded: modesetting,vesa gpu: i915 resolution: 1128x752~60Hz
  OpenGL: renderer: Mesa Intel Graphics (ADL GT2) v: 4.6 Mesa 22.1.6

@M4X yea I think you’re using the Xorg Intel driver when you want to be using modesetting.

…loaded: intel
unloaded: modesetting…

Try removing them, rebuilding initramfs, and rebooting.

pacman -Rsu xf86-video-intel
pacman -Rsu xf86-video-vesa
mkinitcpio -p linux
2 Likes

For folks seeing a hard freeze issue, could you share:

  1. Which distro you are using (most reports here are for Fedora 36, but there are some mentions of other distros).
  2. Which kernel you are on (you can run “uname -v” to check)
  3. Whether you’ve adjusted any kernel parameters, like setting the workaround to disable to ALS (module_blacklist=hid_sensor_hub)
  4. What model of SSD you are using
  5. What circumstances you are seeing the freeze during (e.g. when using a specific application like Settings or uncorrelated to a specific application)
5 Likes

Done, but a crucial piece of information is still missing, i.e. how do I buy you a beer?

In other words, the above fixed the freeze. Thanks @Eddie_Zaneski !

3 Likes

@nrp :

  • Distro: Arch
  • Kernel: #1 ZEN SMP PREEMPT_DYNAMIC Wed, 17 Aug 2022 14:28:00 +0000
  • Additional kernel parameters: none
  • SSD: SN850 bought together with the laptop, with no attempt at updating firmware
  • Circumstances: whenever accessing Gnome Settings → Keyboard → View and customize shortcuts

And:

  • Fix: removing xf86-video-intel and xf86-video-vesa as suggested by @Eddie_Zaneski above.

Do you still have hardware acceleration in, for example, Firefox?

Looks like I do. CPU stays low on 8K videos, and about:support shows:

HW_COMPOSITING:
available by default
OPENGL_COMPOSITING:
available by default
WEBRENDER:
available by default
WEBRENDER_QUALIFIED:
available by default
WEBRENDER_COMPOSITOR:
disabled by default: Disabled by default
blocklisted by env: Blocklisted by gfxInfo
blocked by runtime: Cannot be enabled in release or beta
WEBRENDER_PARTIAL:
available by default
WEBRENDER_SHADER_CACHE:
disabled by default: Disabled by default
WEBRENDER_OPTIMIZED_SHADERS:
available by default
WEBRENDER_ANGLE:
available by default
unavailable by env: OS not supported
WEBRENDER_DCOMP_PRESENT:
available by default
disabled by user: User disabled via pref
unavailable by env: Requires Windows 10 or later
unavailable by runtime: Requires ANGLE
WEBRENDER_SOFTWARE:
available by default
WEBGPU:
disabled by default: Disabled by default
blocked by runtime: WebGPU cannot be enabled in release or beta
X11_EGL:
available by default
DMABUF:
available by default
VAAPI:
disabled by default: VAAPI is disabled by default
VP8_HW_DECODE:
available by default
VP9_HW_DECODE:
available by default
DMABUF_SURFACE_EXPORT:
blocked by default: Blocklisted by gfxInfo
2 Likes

@nrp

I am also seeing these hard freezes. Here is the information you requested:

Framework 12th gen DIY i7-1260P

  1. Fedora 36 (Wayland)
  2. Linux framework 5.18.17-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Aug 11 14:36:06 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
  3. args=“ro rootflags=subvol=root rd.luks.uuid=luks-7f6bf378-c530-43fe-8a9b-cbcbc768fa66 rhgb quiet module_blacklist=hid_sensor_hub”
  4. WD SN850 (WDS500G1X0E-00AFY0)
  5. For me it has only ever happend in Gnome Settings, in various menus. Menus I recall it happening in: Accessibility, Power. It doesn’t happen everytime I go to these menus or Gnome Settings, though. I haven’t recognized any other patterns.

Appreciate any attention given to fixing this if possible!

2 Likes

@nrp

For me, I have gotten the random lock-ups in gnome, but more so after coming out of deep sleep. Coming out of deep sleep is really bad with lock-ups and the screen flickering sometimes.

  • Manjaro
  • Wayland
  • Linux framework-manjaro 5.19.1-3-MANJARO #1 SMP PREEMPT_DYNAMIC Sat Aug 13 06:34:52 UTC 2022 x86_64 GNU/Linux
  • GRUB_CMDLINE_LINUX_DEFAULT=“quiet cryptdevice=UUID=f4b6f1c0-1866-48b5-bb34-cbc1810a1054:luks-f4b6f1c0-1866-48b5-bb34-cbc1810a1054 root=/dev/mapper/luks-f4b6f1c0-1866-48b5-bb34-cbc1810a1054 splash apparmor=1 security=apparmor udev.log_priority=3 mem_sleep_default=deep nvme.noacpi=1”
  • WD SN850 (WDS200T1X0E-00AFY0) - fully updated

@nrp Here’s my config

  1. Fedora 36
  2. Kernel: 5.18.18-200.fc36.x86_64
  3. No additional kernel parameters
  4. SSD: WD SN850
  5. Freezes when using gnome settings (has been a while since I have tested)

Just thought I’d share that I’ve not yet experienced any hard freezes on F36 and the one difference between my setup and the ones posted here is that I’m using a different SSD (Samsung 970 Evo Plus).

@nrp

Had my first hard lock-up earlier (though, I have previously seen similar but brief lockups, that ended under 20 seconds.) This time, full lock, with screen still showing frozen display (i.e. didn’t blank), and CPU fan kicked up really quick into high after about 1 minute of sitting locked; after this, noticeable temp ramp over maybe 1.5 to 2 minutes, thru chassis. Forced power off w/ long button press, due to concern about heat.

  1. Fedora 36
  2. 5.18.18-200.fc36.x86_64
  3. I did set that exact ALS sensor workaround that you mention, via the grubby method found in Fedora install guide. Otherwise, kernel untouched.
  4. SN850
  5. Just browsing w/ Firefox (maybe there was a terminal open on another workspace, but nothing running in it, if so.) Maybe 10 or so tabs, some sites with probably mildly heavy javascript (Indeed, browser client of Discord, nothing else with any weight at all.)
1 Like

Possibly an unrelated issue, but I’ve been encountering brief freezes where the system locks up for 1-2 seconds and then recovers, on Arch lxde, using xorg. The journalctl error is similar to the logs reported by @M4X here:

Aug 23 23:02:27 arichard kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
Aug 23 23:02:27 arichard kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Aug 23 23:02:27 arichard kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
Aug 23 23:02:27 arichard kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
Aug 23 23:02:27 arichard kernel: i915 0000:00:02.0: [drm] HuC authenticated
Aug 23 23:02:27 arichard kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Aug 23 23:02:27 arichard kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled

However, the logs I posted lack the timeout, i.e. it seems to restart successfully and continue instead of freezing permanently. AFAICT, the brief freezes no longer occur if I downgrade to the LTS kernel (5.19.3 → 5.15.62).

  • Distro: Arch Linux with lxde (xorg)
  • Kernel: Brief freezes on 5.19.3; no issues so far on 5.15.62
  • Unusual kernel line: n/a
  • SN850
  • Circumstances: far higher rate of freezing when I have many internet tabs open.

I’m not sure how helpful this will be for others, however I haven’t had any issues now for 2 days. So perhaps it will.

Looking into the behavior I was seeing and testing multiple DEs, for me at least the problems seemed centered around Gnome.

Looking into what was out there, at least in Manjaro, there seems to be some issues between the “Gnome 4x UI Enhancements” and “Dash to Dock” extensions.

I disabled both and have had a much better experience so far.

Knock on wood but so far I have had no more lock-ups, no more few second freezes, and resuming from deep sleep comes back up correctly with out any sort of weird flickering, glitches or crashes inside of Gnome.

So currently the only problem I have left is that sometimes I reboot and the external monitor is detected and other times I have to un-plug and re-plug the docs usb-c cable.

  1. Fedora 36
  2. 5.18.19-200.fc36
  3. Haven’t messed with this yet.
  4. SN850
  5. Usually happens in Gnome settings or the system settings app in Plasma. On Gnome, which I gave up on based on personal preferences) the lockups would be complete. No keyboard input registers, requires a hard power reset to recover. On Plasma you can still get to a virtual console and poke around (and do things like kill the desktop session so you can start another one). I have had some other random display locks on the device while in a Plasma session, usually when I was using an electron app. These were different in that the entire screen would lock for maybe 10-20 seconds, then unfreeze like nothing happened. I haven’t been able to reliably reproduce those freezes.

Has anyone tried the stuff outlined here yet?

I just went through their steps. I need some time to see if I can get it to lock up, but I’m keeping my fingers crossed.