Well, that is another bullet to add to Matt’s table. I didn’t have intel-media-driver installed on my machine. I had intel-mediasdk, but I’m not sure there was any value of having that without the driver, or how I missed the driver… I’m guessing that means there is a low likelihood that intel-media-driver played any affect in the flickering.
On a side note, I just taught another 8 hour session with an external monitor connected and sharing a screen with zoom, same as I did yesterday, but today I didn’t have any flicking issues. The only change I had made between sessions was doing the bios update. Since class ended an hours ago, I’ve added intel-media-driver and oneVPL so I’ll test for any flickering issues during tomorrow’s 8 hour class session. And for reference, I have never gone through an 8 hour class session since getting the 12th gen motherboard 6 months ago and not had flickering atleast 50% of the class session. I have also found that using the CTRL key to locate mouse pointer (used to emphasis bullets in slides while teaching) is a great way to case the flicker to occur on demand during that 50% of the time.
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.
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.
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.
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):
Connected to a Lenovo Dock (AC) while in a video conference (Zoom) (hard freeze of laptop)
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.
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)
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):
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.
