@Aggraxis Anytime! If I had a nickel for every time things like that have caused me wasted hours at home & work, I would’ve been able to retire 10 years ago.
4 Likes
Ugh. Thanks @Jason_H_Young and @Aggraxis. I was fully awake and didn’t notice, so I have only myself to blame.
4 Likes
Yup, I think it works. I’ve tried the things that tended to cause hard freezes, and since doing the enable_psr=0 thing it has been rock solid reliable. Very nice.
4 Likes
I got today multiple hard freezes. I found out that by pressing alt+ctrl+f6 and the alt+ctrl+f2 solved it
I had also experienced the Gnome desktop freezing a number of times with a fresh install of Fedora 37 beta and updates applied on my Framework i7-1260P over the last 3 days.
It was connected at the time to my Dell U4021QW (Thunderbolt) and the freeze was most easily triggered by running the Gnome settings app.
The desktop and mouse would freeze and shortly afterwards the laptop fans would start running. Switching to a virtual terminal (left ctrl, fn, alt, F4) allowed me to login to the console and perform a brief investigation a few times:
gnome-shellwas consuming 100% CPUpsthread listing showed it was the main threaddmesgandjournalctldid not show any GPU error messages (unlike the Fedora 36 reports above)- A brief trace with
straceshowed the process still making a number of system calls - Attaching to the process with
gdband running a backtrace (just the main thread) and stepping through briefly showed it was quite busy running the complex main event loop
I wasn’t set up to properly debug this and not at all familiar with how gnome-shell, Linux drm, nor how the Intel graphics driver works to see an obvious cause.
This morning, a new kernel update came out: kernel-5.19.15-301.fc37.x86_64. The package changelog
rpm -q --changelog kernel-$(uname -r) | less
contains these interesting lines:
- [PATCH] drm/i915: Ensure damage clip area is within pipe area (Mark Pearson)
- [PATCH] drm/i915/psr: Use full update In case of area calculation fails (Mark Pearson)
I’ve updated and rebooted and tried to reproduce the original conditions by running gnome-control-center in a loop that kills it after a short sleep. No freeze yet. Though I never had a reliable way to reproduce the bug. I also made a number of system changes to aid debugging and blacklisted the hid_sensor_hub after the original crashes (but it seems like that wasn’t a factor from reports above?).
For the folks who disabled panel self refresh, it may be worth updating to this kernel if on F37 beta, remove that kernel command line option and see if freezes occur.
6 Likes
Thanks egalanos and a great update.
I’m on Fedora 37 beta. I experienced the hard freeze a few times before adding the options i915 enable_psr=0 configuration. Since then I did actually experience the hard freeze again, but only once.
I’ll grab the kernel update and remove that psr configuration, see how I go.
4 Likes
Alright, so a day or so later. Fedora 37 with kernel 5.19.15-301.fc37.x86_64 and enable_psr setting removed from the i915.conf file.
I have not had any hard freezes. But I did have one occasion where I got a stutter, like a frame drop in a video game, and once it started it continued happening every 10 seconds or so until I rebooted. Unfortunately I forgot to check the journalctl logs for i915 messages before rebooting. If it happens again I’ll check.
I’m pretty sure that you still can, journalctl -b -1 gets you the logs from the last boot.
1 Like
Oh, thanks. I’m slightly embarrassed to admit the last time I was seriously using linux was before systemd, so I’m still catching up.
With sudo journalctl -b -3 I found this:
Oct 20 14:51:21 fedora kernel: i915 0000:00:02.0: [drm] *ERROR* CPU pipe A FIFO underrun: port,transcoder,
However I’m not sure if the log timestamp here, matches the time I got the frame drop/stutter issue. I don’t remember at this point. I’ll keep my eye out.
I just got a freeze for several seconds, thought it was going to be another hard freeze but the system recovered and the mouse started moving again. Found this in the log:
Oct 22 18:05:51 fedora kernel: Asynchronous wait on fence 0000:00:02.0:gnome-shell[1896]:3ae32 timed out (hint:intel_atomic_commit_ready [i915])
Oct 22 18:05:56 fedora kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:0:00000000
Oct 22 18:05:56 fedora kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
I just want to say that I have had this issue every time I re-install Fedora and I re-install weekly. ( I have my reasons).
After disabling ALS, I never see the issue again.
What is ALS?
Ambient Light Sensor.
1 Like
Disabling the ambient light sensor is part of the official setup instructions on both Fedora and Ubuntu. I’ve had that disabled since the very beginning and I still get the occasional [drm] GPU HANG freezes, so I don’t think that’s related. It definitely isn’t the whole picture, for sure.
My freezes have been spaced out far enough that I haven’t messed around with other kernel parameters yet. Out of everything above the psr stuff seems the most promising, but even that hasn’t worked for everyone.
I think with sporadic things like this there’s a lot of room for some placebo effects to take hold: “Folks, I held my laptop upside down for ten minutes and haven’t had any freezes for several hours. Fix confirmed.”
I still hope that a real root cause can be discovered and a fix deployed that doesn’t negatively impact battery life. Fingers crossed!
2 Likes
With the very latest Fedora 37 kernel version 5.19.16-301.fc37.x86_64, automatic light sensor disabled as per the official Framework guide, and only default options for the i915 driver, I’ve been ok this week.
I’ve actually been doing some fairly heavy productivity work on my Framework, lots of web email, downloading and editing Word and PDF documents etc, as well as some moderate programming and compilation work.
It’s been pretty good and I haven’t had a hard freeze again or any issues at a critical moment at least. I think I got one more frame drop/stutter situation where there was a GPU hang recovery so it’s definitely not perfect yet.
Someone on Hacker News linked the official Intel i915 driver issues page which is a good resource. You can search by the GPU Hang ecode e.g. 12:0:00000000 . Sounds like some people are having occasional issues on other laptops as well.
1 Like
I have a 1280P (batch 4) laptop running Fedora Silverblue.
- two USB-C
- one USB-A
- one HDMI
- WD SN850X 4TB
- Kingston Ripjaws 3200MHz 64GB
Kernel: Linux fedora 5.19.16-301.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct 21 15:55:37 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
I disabled the ambient light sensor using the Fedora guide. When I was running Fedora 36 I had several soft lockups and graphical errors. I had one hard lockup while in GNOME display settings. The CPU was getting very hot so eventually I hard-powered down. After upgrading to Fedora 37 I have had soft lockups after waking from sleep and when using programs accelerated by the iGPU (LibreWolf/Firefox/Ungoogled Chromium). A reboot resolved the issues after waking up, but I haven’t resolved the iGPU hangs. All of these issues seem to be bugs in the kernel. If you need a stable experience today, use the 11th gen processor.
If you need a stable experience today, use the 11th gen processor.
I have to agree with that. I’m discovering that 12th gen Intel has issues. Not just Linux on Framework but also Windows and e.g. new Dell laptops it seems flaky.
1 Like
This issue in the tracker seems to be most related:
Adding my experience to the data.
- Fedora 36
- Linux 5.19.16-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Sun Oct 16 22:50:04 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
- module_blacklist=hid_sensor_hub
- 1TB SN850
- Happened when in gnome-settings
Update 2/11/22:
No freezes since the first time. The only thing I changed is I replaced the HDMI extension card with the 1TB instead.
Update 4/11/22: Added i915.enable_psr=0 to my kernel parameters, and I have not had anymore freezers. Running Xubuntu (5.15.0), Fedora (6.0.5) and Pop (6.0.3). HDMI extension card and Anker USB-C hub with HDMI both seem to work equally well.