Docks, a wonderful asset until they’re not. 
While this is not amazing, it’s likely giving us a general direction in which to keep poking at.
1 Like
This may be a red herring. I’m somewhat confident that I’ve seen freezes with no dock/external monitor attached.
In general, it seems that the circumstances under which this occurs are rather hard to determine. We’ve seen a lot of “I did x and now the bug doesn’t appear anymore”, which then later turned out to be wrong. (It may very well the case that certain circumstances make freezing more likely to occur – but I don’t think this will take us further to the root cause.)
2 Likes
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.
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.
@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.
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
Thank you!!
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:
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.
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
@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
Really? That is weird, because Fedora also seems to support grub.
If that file really does not exist, you likey use systemd-boot.
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
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.
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
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
I dont think so, please remove them.
@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
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