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

Framework Laptop 13 Linux
258

@Matt_Hartley I think you’re correct the hard freezing is a chrome/chromium issue. I currently seem to be able to reproduce the hard freeze by reopening tabs from my last chrome session. Writing this on firefox.

Not sure how to get vainfo on fedora but my setup is:

12th Gen Intel
Fedora 37
Wayland
kernel 6.0.10-300.fc37.x86_64

Logs from my last boot where it hung are:

Dec 04 17:59:17 fedora kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:849f3c04, in chrome [4627]
Dec 04 17:59:17 fedora kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Dec 04 17:59:17 fedora kernel: i915 0000:00:02.0: [drm] chrome[4627] context reset due to GPU hang
Dec 04 17:59:17 fedora kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
Dec 04 17:59:17 fedora kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
Dec 04 17:59:17 fedora kernel: i915 0000:00:02.0: [drm] HuC authenticated
Dec 04 17:59:17 fedora kernel: i915 0000:00:02.0: [drm] GuC submission enabled
259

Here are some logs from where it hung but recovered. Not sure if this gives any extra info but I thought the crash annotation line was interesting as it mentions VAAPI, which I got hits for when googling vainfo

Dec 04 18:49:01 fedora kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[1941]:19aac timed out (hint:intel_atomic_commit_ready [>
Dec 04 18:49:04 fedora kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
Dec 04 18:49:04 fedora kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Dec 04 18:49:04 fedora kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
Dec 04 18:49:04 fedora kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
Dec 04 18:49:04 fedora kernel: i915 0000:00:02.0: [drm] HuC authenticated
Dec 04 18:49:04 fedora kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Dec 04 18:49:04 fedora kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Dec 04 18:49:04 fedora firefox.desktop[3355]: Crash Annotation GraphicsCriticalError: |[0][GFX1-]: glxtest: VA-API test failed: failed to initialise VAAPI connection. (t=0.236754) |[1][GFX1-]: GFX: RenderThread detected a device reset in PostUpdate (t=2779.62) [GFX1-]: GFX: RenderThread detected a device reset in PostUpdate
260

More logs after another reboot, restart of chrome with same tabs. This time it recovered after several seconds of complete freeze (e.g. 3-10 seconds)

Dec 04 19:04:15 fedora google-chrome.desktop[3363]: [3358:3358:1204/190415.602027:ERROR:interface_endpoint_client.cc(694)] Message 0 reject
ed by interface blink.mojom.WidgetHost
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.629418:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncPar
ametersIfAvailable() failed for 1 times!
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.633467:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncPar
ametersIfAvailable() failed for 2 times!
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.637816:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncPar
ametersIfAvailable() failed for 3 times!
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.852305:ERROR:shared_image_factory.cc(575)] Could not find Shared
ImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: BGRA_8888, share_between_threads: 0, gmb_type: shared_mem
ory
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.857867:ERROR:shared_image_factory.cc(575)] Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: BGRA_8888, share_between_threads: 0, gmb_type: shared_memory
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.863965:ERROR:shared_image_factory.cc(575)] Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: BGRA_8888, share_between_threads: 0, gmb_type: shared_memory
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.872283:ERROR:shared_image_factory.cc(575)] Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: BGRA_8888, share_between_threads: 0, gmb_type: shared_memory
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.877785:ERROR:shared_image_factory.cc(575)] Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: BGRA_8888, share_between_threads: 0, gmb_type: shared_memory
Dec 04 19:04:16 fedora google-chrome.desktop[3363]: [3476:3476:1204/190416.893201:ERROR:shared_image_factory.cc(575)] Could not find SharedImageBackingFactory with params: usage: Gles2|Raster|DisplayRead|Scanout, format: BGRA_8888, share_between_threads: 0, gmb_type: shared_memory
Dec 04 19:04:18 fedora chronyd[915]: Selected source 81.21.65.168 (2.fedora.pool.ntp.org)
Dec 04 19:04:22 fedora gnome-character[3211]: JS LOG: Characters Application exiting
Dec 04 19:04:27 fedora kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[1866]:bdc timed out (hint:intel_atomic_commit_ready [i915])
Dec 04 19:04:31 fedora kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:849f3c04, in chrome [3476]
Dec 04 19:04:31 fedora kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Dec 04 19:04:31 fedora kernel: i915 0000:00:02.0: [drm] chrome[3476] context reset due to GPU hang
Dec 04 19:04:31 fedora kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
Dec 04 19:04:31 fedora kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
Dec 04 19:04:31 fedora google-chrome.desktop[3363]: [3476:3476:1204/190431.843449:ERROR:shared_context_state.cc(859)] SharedContextState context lost via ARB/EXT_robustness. Reset status = GL_GUILTY_CONTEXT_RESET_KHR
Dec 04 19:04:31 fedora google-chrome.desktop[3363]: [3476:3476:1204/190431.843828:ERROR:gpu_service_impl.cc(988)] Exiting GPU process because some drivers can't recover from errors. GPU process will restart shortly.
Dec 04 19:04:31 fedora kernel: i915 0000:00:02.0: [drm] HuC authenticated
Dec 04 19:04:31 fedora kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Dec 04 19:04:31 fedora kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Dec 04 19:04:31 fedora google-chrome.desktop[3363]: [3723:1:1204/190431.850353:ERROR:command_buffer_proxy_impl.cc(325)] GPU state invalid after WaitForGetOffsetInRange.
Dec 04 19:04:31 fedora google-chrome.desktop[3363]: [3685:1:1204/190431.850573:ERROR:command_buffer_proxy_impl.cc(325)] GPU state invalid after WaitForGetOffsetInRange.
Dec 04 19:04:31 fedora google-chrome.desktop[3363]: [3358:3358:1204/190431.862238:ERROR:gpu_process_host.cc(990)] GPU process exited unexpectedly: exit_code=8704
Dec 04 19:04:31 fedora google-chrome.desktop[3363]: libva error: vaGetDriverNameByIndex() failed with unknown libva error, driver_name = (null)
Dec 04 19:04:32 fedora google-chrome.desktop[3363]: [4127:4127:1204/190432.000425:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 1 times!
Dec 04 19:04:32 fedora google-chrome.desktop[3363]: [4127:4127:1204/190432.001932:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 2 times!
Dec 04 19:04:32 fedora google-chrome.desktop[3363]: [4127:4127:1204/190432.002491:ERROR:gl_surface_presentation_helper.cc(260)] GetVSyncParametersIfAvailable() failed for 3 times!
261

dnf provides vainfo. you need the libva-utils package. Firefox Hardware acceleration - Fedora Project Wiki should help more.

your other info is interesting, kernel 6.0.10, but seeing the ecode 12:0:00000000 error. i’ve not seen it since i upgraded to the 6.0.9 kernel.

fwiw i’ve tried vscodium (afaik chromium based) for around 12hours (some hours in use, mostly idle in background) and no issues with any ecode, which seems to be chrom{e|ium}/app specific based on other responses in this thread.

As you say, there are hints that missing vaapi libs could be related. worth a shot with getting libva setup. When you run vainfo, check for the VLD & EncSlice output lines which indicates vaapi is working.

262

It was a hard freeze had to power down and restart. I forgot to take logs but will next time if it happens.

263

Hello,

I’ve received the Framework laptop last week. I’m really happy with it, but I’ve got similar issues as discussed in this topic. I run arch, gnome, kernel 6.0.11. What I also run into is an issue that I don’t see discussed here: when I the nightlight on and off, the top of the display flickers white.

I’ve made a post about it here, mentioning this post, among another. So far I’ve not received a reply.

Do you also see this behaviour regarding nightlight?

264

Replied. Try suggested to rule out hardware.

1 Like
265

Still got a hard freeze then recovery when trying

enable_psr=0

@Aggraxis how do I undo your solution if I want? Delete the i915.conf file and reboot? Or do I need to run more commands e.g. something with dracut?

1 Like
266

This is what I get when running vainfo:

Trying display: wayland
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: va_openDriver() returns -1
libva info: Trying to open /usr/lib64/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_1_15
libva error: /usr/lib64/dri/i965_drv_video.so init failed
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Seems like libva isn’t configured correctly as it can’t even init?

Edit: and this is after installing libva, libva-utils, libva-intel-driver, ffmpeg, which weren’t installed by default and therefore I couldn’t run vainfo

Edit2: after removing libva-intel-driver and insalling intel-media-driver, vainfo seems to complete successfully:

Trying display: wayland
libva info: VA-API version 1.16.0
libva info: Trying to open /usr/lib64/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_16
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.16 (libva 2.16.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.5.4 ()
vainfo: Supported profile and entrypoints
      VAProfileNone                   :	VAEntrypointVideoProc
      ...
267

In firefox in about:config check if media.ffmpeg.vaapi.enabled is set to true. Close firefox, reopen and see if tha tmakes a difference. If that does not work go back to about:config and set gfx.webrender.all to true.

268

@Kelby_Faessler
You would either comment out the line in the i915.conf or remove the file, then run sudo dracut --force again, followed by a reboot.

1 Like
269

By the way, for anyone looking for more data, I upgraded to F37 without incident some time ago. My i915.conf changes are still in place.

1 Like
270

Happened again. Fedora 37, Linux fedora 6.0.11-300.fc37.x86_64 and I was in gnome-settings.

Tail of journalctl log below. What else should I look for when data collecting?

Dec 09 23:40:57 fedora kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[1973]:15542 timed out (hint:intel_atomic_commit_ready [i915])
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:84dffffb, in gnome-control-c [28845]
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] ERROR rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] ERROR rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] gnome-control-c[28845] context reset due to GPU hang
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] brave[4303] context reset due to GPU hang
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.1.1.bin version 70.1
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] HuC authenticated
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Dec 09 23:41:01 fedora kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled

271

@Elmo it looks like there was a gpu hang on the brave browser process. That doesn’t mean brave was the culrit, but that’s where it happened.

I haven’t been gaming on my laptop in a while, and today after an update it looks like I’m having GPU hangs again - even with the psr=0 parameter. What’s odd is that when using Wayland I can get the display to hang within about 2 minutes just by running circles around in a circle. With X11, although it was running noticeably slower, the system kept running for much longer without hanging up. I’m still digging, but it looks like maybe either Intel or the Wayland folks have something freaky going on.

edit - I haven’t been seeing these hangs under normal use, which for me means some browsing, a horizon client session, and some terminal work.

1 Like
272

image
image1523×1291 454 KB

Man, this makes my insides hurt. So we can see that the kernel module gets loaded, gets its firmware, does some happy normal stuff. I fire off my game, run about 6 circles around the area I’m in, and then VRRRP frozen. This last time it gave me one little burp of frames at the end, and I assume that’s what happened at that spot where the module seems to have been reloaded.

Anyhow, this is all on F37 w/ kernel 6.0.12-300.fc37. Going to be fun teasing this out.

2 Likes
273

Small update on this. Despite running Kernel 6.0.9, I encountered eleven freezes (!) with ecode 12:0:00000000 and one with ecode 12:1:0036abdf since Dec 10th. I’ll update to 6.1 in the coming days now that it’s released. I might also try using xorg instead of Wayland like @Aggraxis suggested.

I also thought it might be related to Ubuntu’s Power Mode (esp. Power Saving) but some freezes occurred in the default Balanced mode.

274

@KevSlashNull In playing with things yesterday I found that I was still able to alt-f3 over to another shell like the previous flavor of freezes. I was also able to get the system responsive again by finding the wayland session process (ps -eaf | grep wayland), killing it, and then in my case restarting the sddm process (systemctl restart sddm). Gnome users will need to restart gdm (systemctl restart gdm) instead.

What’s driving me nuts with this round of freezes is the inconsistency. I can run the aquarium from webglsamples.org with 25,000 fish at 60 fps for more an an hour with no freeze. Firing up FFXIV via xivlauncher and playing the game for not even a minute results in a freeze. AND JUST THE DISPLAY. I’m certain the game is otherwise happily running. The music is definitely playing.

This happens on battery, on AC power, in a house with a mouse, etc.

I took all of the kernel module tweaks out, but nothing changed. I even disabled all of the power saving features in the driver, still no result. I haven’t gotten anything else to barf out more info that anyone’s going to find useful. Still digging. Somehow between all of us out there we’ll figure this out.

275

Ok. I need to do a lot more testing, but for my specific freeze I think I found at least a partial answer:

https://wiki.archlinux.org/title/intel_graphics#Enable_GuC_/_HuC_firmware_loading

Based on that page, it says that that new in Gen12 is using the GuC for “scheduling, context submission, and power management.”

Hmmmmm… Ok, so just for giggles I added options i915 enable_guc = 0, which fully disables the firmware loading. Yes, this probably messes with video playback acceleration, but here’s the kicker:

FFXIV ran for 3 hours straight, and not just me running circles around an Aetheryte. I went all over the place, mined some weird stuff, and put the system through its paces (fan whirring on max the whole time). It ran great,

I commented the line out, re-ran dracut again, and on next boot the game crashed in 47 seconds. So yeah, I need to run more trails, and also check to see if options 1 or 2 make a difference. (I suspect option 2 will work fine, and that it’s 1 or 3 where it loads the GuC Submission that it will go bonkers, but I need to fiddle with it.)

Anyways, if you happen to try that out, let me know how it goes. More info is better.

Ok so far 1 crashed pretty quickly, and 3 (the default) also crashes. 0 ran well, and 2 is running fine right now. Going to abuse it a bit.

1 Like
276

Screenshot_20221218_162650
Screenshot_20221218_1626501920×1281 220 KB

Video acceleration still seems to be working fine with enable_guc=2. No crashes yet. Still abusing. Looks promising.

277

dang I tried enable_guc=0 and enable_guc=2 and I still get freezes when I reopen chrome tabs.