My crashes on Fedora 36 stopped completely once I disabled the Dash To Panel gnome extension. Worth a try if you’re still struggling with this.
Unfortunetaly that doesn’t fix it for me since I never used Dash to panel. The freeze occurs for me with extensions completely disabled too
Need additional data points:
For those who had this happened, is it a Fresh iso-only install (with no connection to the internet)? Or installed, with internet connection (and downloaded updated)?
1 Like
I just followed the Fedora installation instructions which means offline install and connecting to the internet on the welcome screen (and then installing updates). I didn’t test if it happens before I installed updates.
Yesterday I installed Fedora 37 beta and I didn’t have any freezes after that. Maybe Fedora 37 fixes/improves something? 
2 Likes
I haven’t been back here in a while, but I’m still getting issues. Yeeted the xorg drv package, no DP or HDMI adapters installed. One day I played the snot out of a game for hours without issue. (Man does the unit get hot and noisy under load.) Other days it’ll just lock up on me. I was in a Horizon View session doing some remote work and WHAM. Locked up like nobody’s business. I know it’s not framework-specific, but I’m still disappointed to the degree that I’m not recommending the laptop to my friends and co-workers on account of how much trouble I’ve had with this specific issue.
1 Like
There’s a thread here that suggests disabling panel self-refresh as a temporary workaround (i.e. add “i915.enable_psr=0” to the kernel boot parameters).
I’m currently testing this out and will report back if it doesn’t fix the problem.
OS: Fedora Kinoite 37-pre
Kernels: 5.18 and 5.19 (tried rolling back the kernel; still saw lockups when using 5.18)
No kernel extensions
SSD: Hynix P41 1TB
Update: I’ve had the laptop running for a few hours now, and:
(a) I’m not observing any lockups (previously I’d notice stuttering within minutes of starting up); and
(b) journalctl isn’t showing any more messages about the GPU crashing, or “i915 resetting chip for stopped heartbeat on rcs0”.
As an added bonus, the screen tearing upon logging in is now gone.
5 Likes
This mornings crashes coincided with journalctl messages for i915: [drm] ERROR Fault errors on pipe A:L 0x00000080 the first go around, a [drm] Resetting chip for stopped heartbeat on rcs0 the second time around, and then the time period of the horizon client crash had it probing the graphics driver repeatedly, but none of the telltale ‘it crashed’ messages (although the system was definitely frozen and required a power reset).
Anyways, all of that was prior to @ayhcheung 's message re: enable_psr=0. I can clearly see in journalctl where I had called dracut --force after having added options i915 enable_psr=0 to the bottom of /etc/modprobe.d/i915.conf. I have not experienced a crash again yet, and I tried. I fired up horizon, I fired up a game and ran around a crowded area, I played some videos, and I monkeyed around in the settings app. Will continue to torture the machine and let you know.
4 Likes
I don’t have much technical information to add but I did notice a big decrease in freeze-ups after upgrading to F37. However I was still experiencing occasional screen artifacts especially on login as well as my cursor sometimes freezing on monitor 1 while using my cursor on monitor 2. With @ayhcheung 's kernel parameter suggestion both the screen tearing and cursor freezing is gone.
I did experience some issues with gnome, but I think they are related to fractional scaling
@prepaidpyramid have you tried adding the kernel boot argument I referred to earlier in this thread? (i915.enable_psr=0)
It would also help if you identified what distribution and version you’re running, as well as the kernel version.
I’m using arch linux with kernel 5.19.10
Having the same kernel: [ 68.603405] i915 0000:00:02.0: [drm] *ERROR* Fault errors on pipe A: 0x00000080 Issue on void linux but only after resuming from hibernation. Interestingly the screen (window interactions) is still functional and the mouse is visible but everything else is black. Already tried enable_psr=0 as well as something else I found on the Arch wiki (enable_guc which is new in alderlake) but both didn’t change anything. I also tried unaccelerated rendering, this makes the screen flicker rather than black and it eventually recovers after reloading i3 a few times (same error messages though). Not sure why it’s happening though.
Restarting XOrg (in my case Blind Ctrl+Shift+e, click exit in i3) fixes the issue instantly so I’m assuming it’s a sync issue in the igpu.
1 Like
Fixed the issue by chance by setting i915.enable_fbc=0 in kernel parameters, so it seems framebuffer compression was the cause (at least in my case)
2 Likes
How did you validate that this addressed the issue?
Does it have any side-effect?
1 Like
Not sure if it fixes the original issue described, but it does fix *ERROR* Fault errors on pipe A: 0x00000080 being triggered, with the problems that seem to come with it (in my case black screen). Validated by hibernating (loginctl hibernate) and resuming from power-off, previously always triggering glitches or black screens; now hasn’t occurred after trying it a few times.
From the documentation it seems the only side-effect is that it can increase power consumption (by ~0.06 W) compared to compressed framebuffers (see arch wiki: Intel graphics - ArchWiki)
2 Likes
“options i915 enable_psr=0” is still looking good here. I just got done cranking away on a game with no issues. Not even a burp. My lap is super sweaty because the laptop is cooking! LOL!
I went back through journalctl to see if I could find any oddball graphics messages, but I haven’t seen any since changing this option.
1 Like
@James_Adams Pretty sure the DisplayPort adapter is the culprit. Removing it from my wife’s computer and putting one in mine switched around who’s computer was freezing. Then adding it back to her computer caused hers to also freeze again. I just took them out of both and we’ll see what happens.