Applications running in foreground or background when freeze occurs: generally the Firefox rpm
What if anything is attached to your Framework; docks, (BT, IR, wired) mouse, keyboard: second monitor via hdmi, keyboard and mouse over usb, ethernet over usb: freezes occur whether or not anything is attached, nor does battery mode / cable seem to affect them.
Additonal notes
the freezing occurs a few times per day for a few seconds
the flickering of the upper few pixel rows gets markedly worse whenever nightmode is activated and tuning down the blue light during sundown, with nightmode turned off it happens occasionally during the day
FYI: New Intel Media Driver dropped on Fedora 37 today. This one should have a bunch of fixes. SO if you are an infrequent updater, today might be a good day to do so
Thanks @Matt_Hartley for the heads up on the Media Driver in today’s update. I’ll update as soon as I finish this message. I usually updates daily.
I have been experiencing the freezing since receiving my 12th gen board. Here are the details to add to your spreadsheet:
Fedora 36 or 37: 37, and updating almost daily
12th gen or 11th gen: 12th gen
Kernel version: 6.1.7-200
Gnome version: 43.2-1 (at least for gnome-shell
Using i915 fixes, if so, which ones: None
Applications running in foreground or background when freeze occurs: I only experience it when I have an external monitor or external projector connected. I also get it when sharing a screen with zoom, but in every instance that I remember I also had an external monitor connected, so can’t confirm that zoom is contributing to the issue. I know I still get it without zoom, most notably when I have the screen in mirror mode and presenting in front of a class. I’ve only ever seen in on the laptop screen, and the mirrored projector does not show the 2-3 second freeze, nor does the Zoom screenshare show the freeze. I have also had a few hard freezes where a forced shutdown was required, which I’m not sure is related to this issue or not, but have no reason to suspect anything else
What if anything is attached to your Framework; docks, (BT, IR, wired) mouse, keyboard: I have had this occur with nothing but power connected on one USB port and a Framework HDMI or DVI port connected monitor. I have experienced it through both HDMI and DVI ports independently. I have also used presenter devices such as Logitech Spotlight, but also experience it without it.
@Matt_Hartley When you said multimedia updates, were you talking about the pipewire updates? If so, I updated them 24 hours ago, and was still experiencing the flickers today. I don’t see anything related to multimedia available at this moment.
Here is what I updated yesterday and the day before, none of which fixed the flicker issues:
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.
