[TRACKING] Fedora Freezes and Flickering on newer Kernels

Framework Laptop 13 Linux
52

So I did some more digging today. 1) GUC and HUC are enabled by default on Fedora 37 no need for the kernel parameters 2) The following error:

i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
i915 0000:00:02.0: [drm] *ERROR* rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}

appears to be the culprit, the dates match my memory of hard freezes. 3) Also experiencing non-fatal errors in intel_ddi_sync_state, which may be related.

53

Additional trobleshooting revealed that multiple monitors may contribute to the crashing. Logs are clean when the laptop is not attached to the dock. Once it is attached the number of errors in the logs enters the level of spamming. No extensions and entering the activity overview creates a bunch of errors. I am going to do additional testing here with usb-c connections and active displaylink adapter to see if it helps.

Another contributing factor may be hardware acceleration in browsers, however I believe this should be resolved once the new intel-media-driver hits rpmfusion. It is already available on Archlinux so I expect this will drop wthin the next week or so.

54

@Matt_Hartley Sorry, I didn’t see that you had replied to me until yesterday!

I actually just experienced the issue again a few minutes ago, so I looked at the journal and found this before I put my computer in sleep since that seems to unfreeze it:

Jan 06 08:05:18 framestancies plasmashell[6071]: libva info: va_openDriver() returns 0
Jan 06 08:05:18 framestancies plasmashell[6071]: ATTENTION: default value of option mesa_glthread overridden by environment.
Jan 06 08:05:18 framestancies systemd-timesyncd[1288]: Timed out waiting for reply from 220.158.215.21:123 (1.opensuse.pool.ntp.org).
Jan 06 08:05:28 framestancies systemd-timesyncd[1288]: Timed out waiting for reply from 51.38.105.7:123 (1.opensuse.pool.ntp.org).
Jan 06 08:05:32 framestancies systemd-logind[1348]: Power key pressed short.
Jan 06 08:05:32 framestancies dbus-daemon[1920]: [session uid=1000 pid=1920] Activating service name='org.kde.LogoutPrompt' requested by ':1.13' (uid=1000 pid=2068 comm="/usr/bin/ksmserver")
Jan 06 08:05:32 framestancies dbus-daemon[1920]: [session uid=1000 pid=1920] Successfully activated service 'org.kde.LogoutPrompt'
Jan 06 08:05:39 framestancies systemd-timesyncd[1288]: Timed out waiting for reply from 162.159.200.1:123 (2.opensuse.pool.ntp.org).
Jan 06 08:05:48 framestancies kernel: usb 3-7: USB disconnect, device number 3
Jan 06 08:05:48 framestancies kernel: usb 3-7: new full-speed USB device number 6 using xhci_hcd
Jan 06 08:05:48 framestancies kernel: usb 3-7: device descriptor read/64, error -71
Jan 06 08:05:49 framestancies kernel: usb 3-7: device descriptor read/64, error -71
Jan 06 08:05:49 framestancies kernel: usb 3-7: new full-speed USB device number 7 using xhci_hcd
Jan 06 08:05:49 framestancies systemd-timesyncd[1288]: Timed out waiting for reply from 204.2.134.162:123 (2.opensuse.pool.ntp.org).
Jan 06 08:05:49 framestancies kernel: usb 3-7: device descriptor read/64, error -71
Jan 06 08:05:49 framestancies systemd-timesyncd[1288]: Contacted time server 17.253.2.123:123 (2.opensuse.pool.ntp.org).
Jan 06 08:05:49 framestancies systemd-timesyncd[1288]: Initial clock synchronization to Fri 2023-01-06 08:05:49.931245 CST.
Jan 06 08:05:50 framestancies kernel: usb usb3-port7: attempt power cycle
Jan 06 08:05:50 framestancies systemd-logind[1348]: Lid closed.
Jan 06 08:05:50 framestancies systemd-logind[1348]: The system will suspend now!

After looking further through the journal to yesterday, at a time when it also happened, I found this common thread:

Jan 04 10:33:46 framestancies plasmashell[22493]: ATTENTION: default value of option mesa_glthread overridden by environment.

However, I’m not entirely sure this is helpful, as it’s a message so common throughout my log (appearing about 2000 times in the last month).

I also did see your message about the best course of action being perhaps just to wait for an update, and that Red Hat may be working on it. But hopefully this late response is at least somewhat helpful to finding this. Maybe there’s something else in the log I posted that could be a clue.

55

Please see this post and keep an eye on it for Monday. I’m compiling a list coming soon and will then use it to look for common threads. Hard freezing on Fedora 36 with the new 12th gen system - #319 by Matt_Hartley

1 Like
56

Thank you!!

57

Everyone who is experiencing freezing, please reply with this outline below so I can get this into a spreadsheet and track this down for the folks at Fedora. Please use this format. Thanks!

Fedora 36 or 37:

12th gen or 11th gen:

Kernel version:

Gnome version:

Using i915 fixes, if so, which ones:

Has this been tried yet and if so, any difference:

Applications running in foreground or background when freeze occurs:

What if anything is attached to your Framework; docks, (BT, IR, wired) mouse, keyboard:

58

Fedora 37
12th gen -7-1260p
Kernel 6.0.17-300.fc37.x86_64
Gnome 43 Wayland
No fixes used no additional kernel parameters outside of blacklisting the light sensors.
Not planning on using any kernel parameters which decrease battery life unless absolutely necessary
Applications running in foreground or background when freeze occurs: Firefox, Evolution, Gnome Control Center, Gnome Terminal, and Quodlibet.
What if anything is attached to your Framework; Thinkpad Thunderbolt 3 Dock (Gen 1), Logitech Bluetooth Mouse M557, 1 (1920x1080) and 1(3840x2160) display

Additional Notes:
Using Wayland Per Display Scaling
Errors seen when hard freezes occur:
i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
i915 0000:00:02.0: [drm] ERROR rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}
i915 0000:00:02.0: [drm] ERROR rcs0 reset request timed out: {request: 00000001, RESET_CTL: 00000001}

intel_ddi_sync_state errors

journalctl gets spammed with Can’t update stage views actor and anytime I use activities overview with external displays I get JS ERROR: TypeError: workspace is undefined with a bunch of preceeding and following Object .Gjs_ui_workspaceThumbnail_ThumbnailsBox (0x559a0c31d570), has been already disposed — impossible to get any property from it. Essentially every super key press is a about 50 lines in the log of it complaining but doing what it is supposed to do.

All freezes have occurred while docked or attached to peripheral devices. I have had no freezes when it was just the laptop. My last freeze was on Dec 26 2022 at 21:01 EST. I suspect the intel_ddi_sync_state errors will resolve when the intel-media-driver updates. I have seen a drop in occurrence frequency, as the kernel has been updated. Much of this may not be just intel graphics issues but regressions in Gnome to issues that were common when the new overview was rolled out.

59

Hello all,
Long time reader, first-time poster. I know this thread specifically mentions “Fedora,” but I would like to suggest that this is a more general issue. I’m having this screen resolution jumping and jittering and freezing issue on my Framework Laptop running Pop!_OS. And it is driving me bonkers. It does it for me on both X11 and Wayland.

Here is a link to an example video:

And here are my details:
Hardware Model Framework Laptop 12th Gen Intel Core
Memory 32.0 GiB
Processor 12th Gen Intel® Core™ i7-1260P × 16
Graphics Mesa Intel® Graphics (ADL GT2)
Disk Capacity 1.0 TB
OS Name Pop!_OS 22.04 LTS
OS Type 64-bit
GNOME Version 42.6
Windowing System Wayland
Kernel version 6.0.12-76060006-generic

Using i915 fixes No
External monitor Yes

This happens only when I’m not using the recommended (highest) resolution for the Framework Laptop display. I have low vision, so I need to run at lower resolutions to be able to use my system comfortably.

Thanks,
Thomas

60

Hello and welcome!

Why not? This solved the issue for someone else.

61

@Anachron,
I should mention that my Linux skill-level is low. I’ve only toyed with Linux here and there, but six months ago, switched to Linux on Framework as my daily driver.

I did take a look at that post, but I don’t see anything on my machine at this location:
/etc/default/grub

So, I thought maybe that was just for Mint.

Take care,
Thomas

62

Really? That is weird, because Fedora also seems to support grub.

If that file really does not exist, you likey use systemd-boot.

63

He seems to be using PopOS so adding kernel parameters would be something like this here

So using
sudo kernelstub -a “i915.enable_psr=0”
should do it.

1 Like
64

Sorry it’s too early in the morning, I saw the thread title and didn’t read his OS…
Thanks for catching that!

You’re right, PopOS does use kernelstub.

65

Thanks @mcz and @Anachron for your insight, but it still does it.

I ran
sudo kernelstub -a “i915.enable_psr=0”
in the terminal, it didn’t give me any feedback, so I can’t confirm that it took…

Restarted; still does it. Switched back to X11; still does it.

I tried kernelstub -v to see if I can see if the property is set, but it doesn’t show it in the output.

Take care,
Thomas

66

All,
After staring at the output for a bit, I do see it there (did I mention that I’m a little bit low-vision)… sorry.

It says this:
Kernel Boot Options:.quiet loglevel=0 systemd.show_status=false splash “i915.enable_psr=0”

Is it supposed to be in quotes like that? None other key/values are.

Thanks,
Thomas

67

I dont think so, please remove them.

68

@Anachron and @mcz ,
Well. I don’t want to speak too soon, but so far: so good.

Setting the kernel boot option without the quotes seems to have taken care of the issue.
sudo kernelstub -a i915.enable_psr=0

I’ll continue with my daily driving, do more testing and keep an eye on it.

If it wasn’t for good folks like you in this community, I might’a gave up.

Thank you,
Thomas

1 Like
69

Glad to be of service!

If it happens again, feel free to update this thread and give me a ping.

Enjoy your framework!

2 Likes
70

Happy to have stumbled across this thread by chance—I’ve been noticing some weird freezing and flickering/jittering of late, and I’ve so far had no real luck isolating a specific trigger. I’m not sure if what I’m seeing matches the typical experience here, as I haven’t seen any hard freezes, and I don’t use a DE with Fedora. The problem typically manifests as the following:

  1. cursor freezes in place for 2-4 seconds
  2. screen flickers/jitters briefly (looks like a flash of black with some tearing) before control is restored
  3. repeat after 10 or so seconds

Suspending the machine and waking it after a few seconds has resolved the issue in a couple of cases, but there have been other occasions on which a full reboot was necessary.

I don’t have GNOME installed at all (just the Sway window manager), so none of the possible triggers related to GNOME-only features like Night Light apply. I also don’t have any docks or other peripherals connected to my Framework.

I do see a couple—but just a couple!—of these lines in old /var/log/messages logs:

kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000

It doesn’t appear that there’s a corresponding line of this type for every time this problem has occurred, but it does seem like the i915 chip is fairly notorious for causing problems… the options i915 enable_psr=0 fix seems like it might be the best we get for now (although I know Sway 1.8 has a new wlroots that may help in my case).

Will try adding the fix and seeing if it helps until we have a more permanent fix, but in the meantime, here are my answers to the above questions:

Fedora 36 or 37: 37
12th gen or 11th gen: 12th
Kernel version: Linux 6.0.18-300.fc37.x86_64 x86_64
Gnome version: None (Sway 1.7)
Using i915 fixes, if so, which ones: Not yet
Has this been tried yet and if so, any difference: Not yet
Applications running in foreground or background when freeze occurs: Firefox, Thunderbird, Discord, foot
What if anything is attached to your Framework; docks, (BT, IR, wired) mouse, keyboard: Nothing

71

I decided to try out Silverblue two weeks ago, this may or may not help us narrow down whatever is causing these issues.

  • Fedora 36 or 37: 37 Silverblue
  • 12th gen or 11th gen: 1240P
  • Kernel version: 6.1.6-200.fc37.x86_64
  • Gnome version: 43.2
  • Using i915 fixes, if so, which ones: not tried yet
  • Has this been tried yet and if so, any difference: not tried yet
  • 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
  • all layered packages: btop, gnome-tweaks, intel-media-driver, langpacks-de, openssl, powertop, steam-devices, tlp
  • all tweaks:
sudo grubby --update-kernel=ALL --args="module_blacklist=hid_sensor_hub"
sudo grubby --update-kernel=ALL --remove-args="quiet"
sudo grubby --update-kernel=ALL --remove-args="rhgb"
sudo grubby --update-kernel=ALL --args="nvme.noacpi=1"
sudo rpm-ostree kargs --append='mem_sleep_default=deep'