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
~$ 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:
- Which distro you are using (most reports here are for Fedora 36, but there are some mentions of other distros).
- Which kernel you are on (you can run “uname -v” to check)
- Whether you’ve adjusted any kernel parameters, like setting the workaround to disable to ALS (module_blacklist=hid_sensor_hub)
- What model of SSD you are using
- 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-intelandxf86-video-vesaas 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
I am also seeing these hard freezes. Here is the information you requested:
Framework 12th gen DIY i7-1260P
- Fedora 36 (Wayland)
- 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
- args=“ro rootflags=subvol=root rd.luks.uuid=luks-7f6bf378-c530-43fe-8a9b-cbcbc768fa66 rhgb quiet module_blacklist=hid_sensor_hub”
- WD SN850 (WDS500G1X0E-00AFY0)
- 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
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
- Fedora 36
- Kernel: 5.18.18-200.fc36.x86_64
- No additional kernel parameters
- SSD: WD SN850
- 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).
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.
- Fedora 36
- 5.18.18-200.fc36.x86_64
- I did set that exact ALS sensor workaround that you mention, via the
grubbymethod found in Fedora install guide. Otherwise, kernel untouched. - SN850
- 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.
- Fedora 36
- 5.18.19-200.fc36
- Haven’t messed with this yet.
- SN850
- 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.
Seems like I resolved the problem (so far one day without any crash, even with VA-API enabled).
My solution: add this kernel param:
i915.request_timeout_ms=60000
If it still doesn’t work, add this:
i915.request_timeout_ms=60000 intel_iommu=off i915.reset=0 i915.enable_psr=0 i915.enable_fbc=0 i915.disable_power_well=1 i915.enable_guc=0
If still doesn’t work, run this on boot:
echo 400 | sudo tee /sys/class/drm/card0/gt_min_freq_mhz;
echo 10000 | sudo tee /sys/class/drm/card0/engine/rcs0/preempt_timeout_ms;
echo 10000 | sudo tee /sys/class/drm/card0/engine/rcs0/heartbeat_interval_ms;
echo 1000 | sudo tee /sys/class/drm/card0/engine/rcs0/stop_timeout_ms;
Old answer
I’ve been working on this issue for over a month now. What I observed:
- It hangs more frequently if you use HW acceleration decoder (va-api for example)
- Disable GuC Submission does make it a bit stable (add kernel param
i915.enable_guc=2). See Intel graphics - ArchWiki - I remap Alt+F12 to trigger a session logout with
gnome-session-quit --forcecommand, so whenever the GPU is hangs, I don’t need to restart the whole computer. - Since the logout method above works fine, I suspect that GNOME does not handle GPU context reset correctly. Let’s hopt that it will be fixed by GNOME.
- I added these kernel param:
915.enable_psr=0 i915.enable_fbc=0 i915.disable_power_well=1 intel_iommu=igfx_off. It seems to be a bit more stable.
My system: Framework laptop i7-1260P, 16GBx2 RAM, Samsung SSD 980 Pro 1TB, Fedora 36 with stock kernel 5.18.17
P/s: I tried Xanmod kernel 5.19, nothing changes.
2 Likes