[TRACKING] Fedora Freezes and Flickering on newer Kernels

I am typing this on Fedora right now - not able to replicate this on my end.

I have alerted my contact with the Fedora project and they indicated they too, had not seen any problems on their Framework either which make me wonder what possible common denominator might be at play.

Based on what you am seeing in your template.

Are you straight HDMI to HDMI or is there one of those DVI adapters involved by chance? I’ve seen them do weird things about 50% of the time in my own experience (other distros).

Zoom and WebRTC screen-sharing has been pretty wild with some browsers. I’ve seen oddness with Google Meet, Jitsi for example with Chrome, but better with Firefox. Whatever browser you use, I’d split test by disabling hardware acceleration in the browser.

1 Like

FYI: Another intel-gpu-firmware update dropped this morning.

I would like to point out that I have very similar issues:

  • Upper rows flickering just after wake up
  • Occasional full screen flickering observed, but rarely
  • Also 5 to 10 seconds freezes that appear maybe once every 1h

However, I’m not on Fedora, but Manjaro.

Some info about my system:

  • DIY 12th gen i5-1240P
  • Kernel 6.1.11-1
  • Manjaro stable
  • Gnome 43.2
  • X11
  • nothing attached to the laptop apart from the power cord

Toss in my latest experience into the ring.

On 12th gen right now, Fedora 37 Workstation, 6.1.11-200.fc37.x86_64, Wayland.

  • 2xUSB-C, one for power, the other for USB hub.
  • 1xHDMI expansion card direct connect to my 2k AOC display (#1)
  • 1xDP expansion card direct connect to my 2k AOC display (#2)
  • Cheap Lionwei USB-C hub. Ports connected are exclusively USB-A. Powering one Steelseries wireless direct headset dongle, G305 mouse, wired keyboard, Logitech BRIO Ultra webcam (1920x1080 @ 60FPS).
  • Bluetooth connection (using right now) JBL headphones, A2DP Sink, codec SBC-XQ.
  • Gnome is set to Performance mode, no TLP installed as I’m plugged into AC power. Flawless performance. Runs really well here.

If anything changes, I’ll updated.

i’m running cinnmon on fedora 37.

i had some issues with flickering after waking up displays, but nothing too bad - only a few seconds, and as soon as there was some redraw it stopped flickering.

BUT

this morning, i went from 6.1.9 to 6.1.11, and my display is no longer working - neither connected through thunderbolt → anker dock → hdmi nor through the hdmi dongle on the laptop itself.

dmesg says:

[   41.009244] ------------[ cut here ]------------
[   41.009245] i915 0000:00:02.0: AUX USBC2/DDI TC2/PHY TC2: not started (status 0xac2003ff)
[   41.009299] WARNING: CPU: 11 PID: 145 at drivers/gpu/drm/i915/display/intel_dp_aux.c:249 intel_dp_aux_xfer+0x6ec/0x780 [i915]
[   41.009384] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer xt_conntrack xt_MASQUERADE nf_conntrack_netlink xt_addrtype nft_compat br_netfilter bridge rpcsec_gss_krb5 stp auth_rpcgss llc nfsv4 dns_resolver nfs lockd grace fscache netfs nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set overlay nf_tables nfnetlink qrtr bnep sunrpc binfmt_misc vfat fat snd_sof_pci_intel_tgl snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof snd_hda_codec_hdmi snd_sof_utils iwlmvm snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi intel_tcc_cooling soundwire_bus snd_hda_codec_idt x86_pkg_temp_thermal intel_powerclamp mac80211 snd_hda_codec_generic snd_soc_core ledtrig_audio coretemp snd_compress ac97_bus snd_pcm_dmaengine snd_hda_intel snd_intel_dspcfg
[   41.009418]  kvm_intel snd_usb_audio snd_intel_sdw_acpi snd_hda_codec cros_usbpd_logger libarc4 kvm snd_usbmidi_lib snd_hda_core uvcvideo cros_usbpd_charger cros_ec_chardev cros_ec_sysfs btusb cros_usbpd_notify snd_hwdep snd_rawmidi irqbypass iTCO_wdt snd_seq videobuf2_vmalloc btrtl rapl videobuf2_memops iwlwifi mei_hdcp cros_ec_dev mei_wdt mei_pxp snd_seq_device intel_cstate btbcm intel_pmc_bxt ee1004 videobuf2_v4l2 hid_sensor_als iTCO_vendor_support snd_pcm processor_thermal_device_pci btintel intel_rapl_msr videobuf2_common hid_sensor_trigger processor_thermal_device pmt_telemetry cros_ec_lpcs hid_sensor_iio_common btmtk pmt_class processor_thermal_rfim industrialio_triggered_buffer cros_ec intel_uncore videodev wmi_bmof pcspkr snd_timer kfifo_buf processor_thermal_mbox bluetooth cfg80211 mc processor_thermal_rapl snd industrialio mei_me thunderbolt i2c_i801 intel_rapl_common joydev rfkill soundcore int3403_thermal mei i2c_smbus idma64 intel_vsec igen6_edac int3400_thermal
[   41.009452]  int340x_thermal_zone acpi_thermal_rel acpi_pad zram dm_crypt uas usb_storage hid_logitech_hidpp i915 r8152 mii drm_buddy nvme drm_display_helper nvme_core crct10dif_pclmul crc32_pclmul crc32c_intel cec polyval_clmulni ucsi_acpi polyval_generic hid_multitouch hid_sensor_hub ghash_clmulni_intel sha512_ssse3 typec_ucsi serio_raw ttm typec nvme_common i2c_hid_acpi video i2c_hid wmi pinctrl_tigerlake hid_logitech_dj fuse
[   41.009469] CPU: 11 PID: 145 Comm: kworker/11:1 Not tainted 6.1.9-200.fc37.x86_64 #1
[   41.009472] Hardware name: Framework Laptop (12th Gen Intel Core)/FRANMACP08, BIOS 03.05 08/23/2022
[   41.009474] Workqueue: events i915_hotplug_work_func [i915]
[   41.009539] RIP: 0010:intel_dp_aux_xfer+0x6ec/0x780 [i915]
[   41.009603] Code: 00 4c 8b 67 50 4d 85 e4 75 03 4c 8b 27 e8 6c 35 18 f4 41 89 d8 48 89 e9 4c 89 e2 48 89 c6 48 c7 c7 e0 08 85 c0 e8 8a a3 5c f4 <0f> 0b 48 8b 44 24 20 89 98 10 06 00 00 bb f0 ff ff ff e9 2b fe ff
[   41.009605] RSP: 0000:ffffb270806dfa78 EFLAGS: 00010282
[   41.009607] RAX: 000000000000004d RBX: 00000000ac2003ff RCX: 0000000000000000
[   41.009608] RDX: 0000000000000001 RSI: ffffffffb574c47b RDI: 00000000ffffffff
[   41.009609] RBP: ffff9d9090674860 R08: 0000000000000000 R09: ffffb270806df918
[   41.009609] R10: 0000000000000003 R11: ffffffffb61465a8 R12: ffff9d908322d6d0
[   41.009610] R13: 0000000000000004 R14: ffff9d908fac1c20 R15: ffff9d908fac0000
[   41.009611] FS:  0000000000000000(0000) GS:ffff9d9fef8c0000(0000) knlGS:0000000000000000
[   41.009612] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   41.009613] CR2: 00007f229dbf01c0 CR3: 000000096f010005 CR4: 0000000000770ee0
[   41.009614] PKRU: 55555554
[   41.009615] Call Trace:
[   41.009617]  <TASK>
[   41.009619]  ? schedule_hrtimeout_range_clock+0xbd/0x100
[   41.009623]  intel_dp_aux_transfer+0x121/0x320 [i915]
[   41.009685]  drm_dp_dpcd_access+0x96/0x110 [drm_display_helper]
[   41.009696]  drm_dp_dpcd_read+0xb5/0x1d0 [drm_display_helper]
[   41.009704]  drm_dp_cec_unset_edid+0x8d/0xd0 [drm_display_helper]
[   41.009712]  intel_dp_detect+0x50a/0x6c0 [i915]
[   41.009774]  ? ww_mutex_lock+0x14/0x80
[   41.009779]  drm_helper_probe_detect_ctx+0x44/0xe0
[   41.009783]  intel_encoder_hotplug+0x43/0xf0 [i915]
[   41.009851]  intel_ddi_hotplug+0x83/0x420 [i915]
[   41.009910]  ? psi_group_change+0x15f/0x380
[   41.009913]  i915_hotplug_work_func+0x182/0x2f0 [i915]
[   41.009971]  process_one_work+0x1c4/0x380
[   41.009974]  worker_thread+0x4d/0x380
[   41.009975]  ? _raw_spin_lock_irqsave+0x23/0x50
[   41.009977]  ? rescuer_thread+0x380/0x380
[   41.009978]  kthread+0xe6/0x110
[   41.009980]  ? kthread_complete_and_exit+0x20/0x20
[   41.009982]  ret_from_fork+0x1f/0x30
[   41.009986]  </TASK>
[   41.009987] ---[ end trace 0000000000000000 ]---

I had similar issues until I updated to the 3.06 beta bios. If you choose to do so, read and follow the instructions precisely.

Also did you shutdown and perform a cold boot?

Since the log mentions kernel 6.1.9 I would assume that that is the kernel actually running.
I have no issues using 6.1.11 on Fedora 37 and BIOS 3.05 with a Microsoft surface USB C to HDMI dongle.

Something that may be helpful when docks are involved is trying this after determining the naming scheme of the display(s), trying the following:

video=DP-1:1920x1080M@60

In my case, I had a DP (#1) that wasn’t activating at boot at all. By adding the video=DP-1:1920x1080M@60 grub, I was able to force the display to wake up and perform the desired resolution and framerate. Use xrandr or similar to determine the display name and the desired resolution/framerate.

I also experience the GPU hangs and flickering display on Fedora 37. This happened a few times to me (not always, not every day):

  1. Connected to a Lenovo Dock (AC) while in a video conference (Zoom) (hard freeze of laptop)
  2. When waking from s2idle (top few display lines flicker, screen updates pause for a few seconds, hard freeze of laptop)

It also occurs when the HDMI expansion card isn’t connected - so it’s not related to it.

Journalctl shows (searching for “GPU HANG”):

Feb 20 15:16:19 framework kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:4c0452c8, in gnome-control-c [112845]
Feb 20 15:16:19 framework kernel: i915 0000:00:02.0: [drm] gnome-control-c[112845] context reset due to GPU hang
Feb 20 15:16:19 framework kernel: i915 0000:00:02.0: [drm] CanvasRenderer[14346] context reset due to GPU hang
Feb 21 20:20:51 framework kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
Feb 21 20:39:15 framework kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000

It seems to happen much more often when on battery than when on AC, but not always. Will try i915.enable_psr=0 as a kernel arg with my next boot.

I’m happy to help, try things, write emails/chat, etc.

Fedora 36 or 37: 37, updating almost daily
12th gen or 11th gen: 12th gen
Kernel version: 6.1.11
Gnome version: 43.3 (at least for gnome-shell)
Using additional Kernel args: module_blacklist=hid_sensor_hub nvme.noacpi=1
Changes from default config: TLP, intel-media-driver
Bios: 3.05

EDIT:
Adding i915.psr_safest_params=1 (no psr=0 yet) to the kernel args (now on 6.1.12) got no effect. There are still some flickering top lines after wake from s2idle and rendering hickups.
What I observe in journalctl is:

Feb 23 07:52:13 framework systemd[2441]: Started dbus-:1.2-com.intel.dleyna\x2drenderer@18.service.
Feb 23 07:52:13 framework dleyna-renderer-service[27009]: dLeyna core version 0.6.0
Feb 23 07:52:13 framework dleyna-renderer-service[27009]: dleyna-renderer-service version 0.6.0
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Type[0] Level[0x13] Mask[0x4C] Flags[0x4F]
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Load file [/home/.../.config/dleyna-renderer-service.conf]
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: [General settings]
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Never Quit: F
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Connector Name: dbus
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Port: 0
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Push host port: 0
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: [Logging settings]
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Log Type : 0
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Log Level: 0x13
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: [Network filtering settings]
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Enabled : F
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Entries: (null)
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Calling GetRenderers method
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: Client :1.573 lost
Feb 23 07:52:14 framework dleyna-renderer-service[27009]: dLeyna: Exit

I’m not quite sure why dleyna might be related, but it was discontinued by Intel. The same few lines occur quite often in my logs and sometimes (not always) align with display issues from a timing perspective. As you can see in the logs, the Client is lost after some time. I’m not sure whether this is the expected behaviour.

Has been tested without the dock? I have been dock testing and they absolutely can in some cases do creative things in my own testing.

I’m using a Lenovo USB-C dock. In general, I’m totally with you - docks can cause weird stuff. I can’t tell whether it’s related to the dock or not, but I doubt it. I’ve seen hickups when the laptop was never connected to anything at all on that boot (except wifi). So, I guess the hard freeze on the dock was just a coincidence. Also, it seems the laptop runs more stable when connected to the dock (internal display deactivated via gnome, 2 external displays, AC).

Issues (flickering lines at the top, screen update pauses for a few seconds) occur mainly (not always) when the laptop was in s2idle overnight and right after (within first 10 mins) the lid was opened in the morning (running on battery all the time). Last time it happened, there was no connection to anything (except wifi) on that boot. When issues occur, it either ends in a hard freeze (just once so far, without the dock) or the issues magically vanish.

Note: I haven’t applied psr=0 yet (wanted to test things)

1 Like

I’ve applied the following kernel parameters so far (PSR = panel self refresh, no psr=0 parameter):

  • no parameters - results in PSR version 2. I experienced screen update issues and freezes (about one hard freeze every 2 days)
  • i915.psr_safest_params=1 - results in PSR version 2 with safer parameters. The screen update issues and freezes didn’t change from no parameters
  • i915.enable_psr=1- activates PSR version 1. This seems to cause less issues than PSR version 2, but not none. I had no hard freeze in 5 days and way less screen update issues. If the latter occurred, they took less time to vanish.
  • i915.enable_psr=0 - deactivates PSR entirely. I haven’t tested with this parameter too much, but according to other users, it seems to resolve all issues.

Power usage (measured by watching powertop for some time in idle state; always under the same conditions) - not perfect, but it’s a first estimation:

  • no parameters - my baseline usage, about 2.3 - 2.5W
  • i915.psr_safest_params=1 (no psr=0) - about 2.3 - 2.5W (no change from no parameters)
  • i915.enable_psr=1- about 2.3 - 2.5W (no change from no parameters)
  • i915.enable_psr=0 - >=3.3W - disabling PSR seems to increase the power usage by about 0.8W (can someone replicate that?). Seems to be in a viable range for PSR, as other people on the web reported either no change or an increase of up to 0.7W (for other laptops).

So my current goto solution is to stick with PSR version 1, as a few seconds of screen update issues (about every two days) are okay for less power usage. I will report back in case freezes appear.

Yes I can. Well at least for idle power usage it seems to be 0.8W for me as well.

I also had a crash today. Or more a hard freeze. But the screen did not update after 2 minutes of waiting so I “rebooted” using a long press of the power button.

Fedora 36 or 37: 37, recently updated (2 days ago at the time of the crash)
12th gen or 11th gen: 12th gen
Kernel version: 6.1.13
Gnome version: 43.3 (at least for gnome-shell)
Using additional Kernel args: module_blacklist=hid_sensor_hub workqueue.power_efficient=true
Changes from default config: TLP, intel-media-driver from rpmfusion repo
Bios: 3.05
Applications running in foreground or background when freeze occurs: Just firefox, single tab open, more or less right after a website loaded. The page was relatively oldschool without much action/javascript and no videos or anything.
What if anything is attached to your Framework; docks, (BT, IR, wired) mouse, keyboard: Framework charger, nothing else

Log from the freeze:

Feb 28 08:26:07 fw1 kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[2586]:73726 timed out (hint:intel_atomic_commit_ready [i915])
Feb 28 08:26:12 fw1 kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
Feb 28 08:26:12 fw1 kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Feb 28 08:26:12 fw1 kernel: i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1
Feb 28 08:26:12 fw1 kernel: i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3
Feb 28 08:26:12 fw1 kernel: i915 0000:00:02.0: [drm] HuC authenticated
Feb 28 08:26:12 fw1 kernel: i915 0000:00:02.0: [drm] GuC submission enabled
Feb 28 08:26:12 fw1 kernel: i915 0000:00:02.0: [drm] GuC SLPC enabled
Feb 28 08:26:12 fw1 systemd[1]: flatpak-system-helper.service: Deactivated successfully.
Feb 28 08:26:12 fw1 audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=flatpak-system-helper comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Feb 28 08:26:12 fw1 systemd[1]: flatpak-system-helper.service: Consumed 1min 42.684s CPU time.
Feb 28 08:26:16 fw1 kernel: Fence expiration time out i915-0000:00:02.0:Renderer[41743]:939e!
Feb 28 08:26:16 fw1 kernel: Fence expiration time out i915-0000:00:02.0:Renderer[41743]:93a0!
Feb 28 08:26:49 fw1 tlp[45135]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.
Feb 28 08:26:49 fw1 tlp[45135]: >>> Invoke 'systemctl mask systemd-rfkill.service' to correct this.
Feb 28 08:26:49 fw1 tlp[45135]: Warning: systemd-rfkill.socket is not masked, radio device switching may not work as configured.
Feb 28 08:26:49 fw1 tlp[45135]: >>> Invoke 'systemctl mask systemd-rfkill.socket' to correct this.
Feb 28 08:27:42 fw1 tlp[45184]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.
Feb 28 08:27:42 fw1 tlp[45184]: >>> Invoke 'systemctl mask systemd-rfkill.service' to correct this.
Feb 28 08:27:42 fw1 tlp[45184]: Warning: systemd-rfkill.socket is not masked, radio device switching may not work as configured.
Feb 28 08:27:42 fw1 tlp[45184]: >>> Invoke 'systemctl mask systemd-rfkill.socket' to correct this.
Feb 28 08:28:30 fw1 tlp[45229]: Warning: systemd-rfkill.service is not masked, radio device switching may not work as configured.
Feb 28 08:28:30 fw1 tlp[45229]: >>> Invoke 'systemctl mask systemd-rfkill.service' to correct this.
Feb 28 08:28:30 fw1 tlp[45229]: Warning: systemd-rfkill.socket is not masked, radio device switching may not work as configured.
Feb 28 08:28:30 fw1 tlp[45229]: >>> Invoke 'systemctl mask systemd-rfkill.socket' to correct this.

As you can see from the annoying tlp Warnings, the system was more or less alive but since the screen did not update also fairly unuseable. Maybe holding the powerbutton isn’t necessary and we could just Alt+F2 and blindly type “reboot” or something. Maybe even restart gdm try to get graphics back in a working state.

I also noticed really stuttery behavior before while using the gnome nightlight function if it actually changes the screen colour. But since I don’t need that feature I just turned it off and never tested further. System did not become totally stuck though just about 2-3 seconds of input lag basically.

Just to reiterate again for my Fedora 37 install, no freezes.

Fedora 36 or 37: 37, recently updated
12th gen or 11th gen: 12th gen
Kernel version: 6.1.13-200.fc37.x86_64
Gnome version: 43.3
Using additional Kernel args: rhgb quiet nvme.noacpi=1 module_blacklist=hid_sensor_hub
(Note: I have no other parameters here, no random power saving items, etc)
Changes from default config: TLP installed.

Applications running in foreground or background when freeze occurs: No freezing.

Then it has to be a difference in installed packages. My system isn’t too old. Here is what I installed via dnf install before my first freeze occurred (in this order, retrieved via dnf history):

arc-theme zsh numix-icon-theme
fzf tlp smartmontools
powertop numix-icon-theme-circle
fedy
cabextract lzip p7zip p7zip-plugins unrar
>> dnf groupinstall multimedia
ocrmypdf nextcloud-client-nautilus
evolution-ews evolution-spamassassin
https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-37.noarch.rpm
intel-media-driver ffmpeg-free tlp-rdw

Here’s what sudo dnf history userinstalled reports for my current system:

Packages installed by user
ShellCheck-0.8.0-3.fc37.x86_64
aajohan-comfortaa-fonts-3.101-5.fc37.noarch
abseil-cpp-20220623.1-2.fc37.x86_64
anaconda-37.12.6-1.fc37.x86_64
anaconda-install-env-deps-37.12.6-1.fc37.x86_64
anaconda-live-37.12.6-1.fc37.x86_64
arc-theme-20221218-1.fc37.noarch
autocorr-de-1:7.4.5.1-1.fc37.noarch
bluez-obexd-5.66-4.fc37.x86_64
cabextract-1.9.1-4.fc37.x86_64
chkconfig-1.21-1.fc37.x86_64
cmark-lib-0.29.0-7.fc37.x86_64
containers-common-extra-4:1-80.fc37.noarch
dracut-live-057-5.fc37.x86_64
evolution-3.46.4-1.fc37.x86_64
evolution-ews-3.46.4-1.fc37.x86_64
evolution-langpacks-3.46.4-1.fc37.noarch
evolution-spamassassin-3.46.4-1.fc37.x86_64
fedy-5.0.23-1.fc37.noarch
fzf-0.35.1-1.fc37.x86_64
glibc-langpack-de-2.36-9.fc37.x86_64
gnome-tweaks-42~beta-4.fc37.noarch
gparted-1.4.0-2.fc37.x86_64
gstreamer1-plugin-libav-1.20.5-1.fc37.x86_64
gstreamer1-plugins-bad-free-devel-1.20.5-1.fc37.x86_64
gstreamer1-plugins-bad-free-extras-1.20.5-1.fc37.x86_64
gstreamer1-plugins-bad-free-fluidsynth-1.20.5-1.fc37.x86_64
gstreamer1-plugins-bad-free-wildmidi-1.20.5-1.fc37.x86_64
gstreamer1-plugins-bad-free-zbar-1.20.5-1.fc37.x86_64
gstreamer1-plugins-good-extras-1.20.5-1.fc37.x86_64
highlight-4.2-2.fc37.x86_64
htop-3.2.2-2.fc37.x86_64
hunspell-de-20161207-4.fc37.noarch
hyphen-de-0.20060120-28.fc37.noarch
initscripts-10.17-1.fc37.x86_64
intel-media-driver-22.5.4-3.fc37.x86_64
ipscan-3.9.1-1.x86_64
kernel-6.1.11-200.fc37.x86_64
kernel-6.1.12-200.fc37.x86_64
kernel-6.1.13-200.fc37.x86_64
kernel-core-6.1.11-200.fc37.x86_64
kernel-core-6.1.12-200.fc37.x86_64
kernel-core-6.1.13-200.fc37.x86_64
kernel-modules-6.1.11-200.fc37.x86_64
kernel-modules-6.1.12-200.fc37.x86_64
kernel-modules-6.1.13-200.fc37.x86_64
kernel-modules-extra-6.1.11-200.fc37.x86_64
kernel-modules-extra-6.1.12-200.fc37.x86_64
kernel-modules-extra-6.1.13-200.fc37.x86_64
lame-3.100-13.fc37.x86_64
lame-devel-3.100-13.fc37.x86_64
langpacks-core-de-3.0-26.fc37.noarch
langpacks-core-font-de-3.0-26.fc37.noarch
langpacks-de-3.0-26.fc37.noarch
langpacks-en-3.0-26.fc37.noarch
libeot-0.01-19.fc37.x86_64
libmd-1.0.4-2.fc37.x86_64
libmysofa-1.2.1-3.fc37.x86_64
libreoffice-help-de-1:7.4.5.1-1.fc37.x86_64
libreoffice-langpack-de-1:7.4.5.1-1.fc37.x86_64
libvirt-client-8.6.0-5.fc37.x86_64
libytnef-1:2.0-2.fc37.x86_64
lm_sensors-3.6.0-12.fc37.x86_64
lzip-1.23-2.fc37.x86_64
man-pages-de-4.15.0-2.fc37.noarch
mesa-va-drivers-freeworld-22.3.5-1.fc37.x86_64
mythes-de-0.20220716-2.fc37.noarch
nextcloud-client-nautilus-3.7.3-1.fc37.x86_64
numix-icon-theme-21.10.31-3.fc37.noarch
numix-icon-theme-circle-21.12.05-3.fc37.noarch
ocrmypdf-14.0.1-1.fc37.noarch
oneVPL-2022.2.2-1.fc37.x86_64
oneVPL-intel-gpu-22.5.3-1.fc37.x86_64
optipng-0.7.7-10.fc37.x86_64
p7zip-16.02-24.fc37.x86_64
p7zip-plugins-16.02-24.fc37.x86_64
powertop-2.15-1.fc37.x86_64
pulsar-1.102.0-1.x86_64
qemu-user-static-2:7.0.0-13.fc37.x86_64
qemu-user-static-aarch64-2:7.0.0-13.fc37.x86_64
qemu-user-static-alpha-2:7.0.0-13.fc37.x86_64
qemu-user-static-arm-2:7.0.0-13.fc37.x86_64
qemu-user-static-cris-2:7.0.0-13.fc37.x86_64
qemu-user-static-hexagon-2:7.0.0-13.fc37.x86_64
qemu-user-static-hppa-2:7.0.0-13.fc37.x86_64
qemu-user-static-m68k-2:7.0.0-13.fc37.x86_64
qemu-user-static-microblaze-2:7.0.0-13.fc37.x86_64
qemu-user-static-mips-2:7.0.0-13.fc37.x86_64
qemu-user-static-nios2-2:7.0.0-13.fc37.x86_64
qemu-user-static-or1k-2:7.0.0-13.fc37.x86_64
qemu-user-static-ppc-2:7.0.0-13.fc37.x86_64
qemu-user-static-riscv-2:7.0.0-13.fc37.x86_64
qemu-user-static-s390x-2:7.0.0-13.fc37.x86_64
qemu-user-static-sh4-2:7.0.0-13.fc37.x86_64
qemu-user-static-sparc-2:7.0.0-13.fc37.x86_64
qemu-user-static-x86-2:7.0.0-13.fc37.x86_64
qemu-user-static-xtensa-2:7.0.0-13.fc37.x86_64
rpmfusion-free-release-37-1.noarch
rpmfusion-nonfree-release-37-1.noarch
smartmontools-1:7.3-3.fc37.x86_64
sqlite-3.40.0-1.fc37.x86_64
sysfsutils-2.1.1-4.fc37.x86_64
tesseract-osd-4.1.0-4.fc37.noarch
tlp-1.5.0-4.fc37.noarch
tlp-rdw-1.5.0-4.fc37.noarch
unrar-6.2.5-1.fc37.x86_64
util-linux-user-2.38.1-1.fc37.x86_64
youtube-dl-2021.12.17-4.fc37.noarch
zsh-5.9-2.fc37.x86_64

Right out of the gate, two differences I noted:

workqueue.power_efficient=true

and

intel-media-driver from rpmfusion repo

Your log indicates a GPU hang and you have an rpmfusion video driver installed. I think this might be a good starting place.

Well it is only the VAAPI driver and has nothing to do with video output. And it is kinda necessary if you want to use hardware video decoding. Firefox Hardware acceleration - Fedora Project Wiki

I love to test without this but since I haven’t had those freezes in 2 months it really doesn’t make sense (as in: not gonna wait 2 months again before something happens). Maybe someone with more trouble can verify the problem persists (or doesn’t?) with/without intel-media-driver.

It sounds like it’s not happening anymore or at least not often enough to be a deal breaker. So that’s good. :slight_smile:

I’ll give it a try - I removed intel-media-driver and all intel related kernel parameters.

Just to note: without intel-media-driver (oneVPL is still installed), neither ffmpeg nor firefox can use QSV algorithms (=GPU accelerated decoding/encoding) currently.

Let’s be real here. There are plenty of rpmfusion packages that are almost a hard requirement to have a functional desktop. These are packages that some distributions ship directly but Fedora won’t because of FOSS. The intel-media-driver is definitely a contributor to the issue at hand, and likely the primary culprit across distros. So what’s my point? Please don’t slam on rpmfusion you can only package what is available, and upstream is broke, under construction etc. For anyone that want’s to use their equipment in a reasonable manner rpmfusion is not just a suggestion, it is essentially required.