I’m running openSUSE Tumbleweed KDE (X11) with the latest kernel, and I’ve been experiencing similar issues. Specifically, the screen will occasionally freeze over and over again for a time. I’ve tried setting kernel parameters like intel_idle.max_cstate=3 per others’ suggestions, but they haven’t completely rectified the issue. I haven’t experienced the issue yet on Ubuntu, and probably won’t since I only tested it briefly, but yeah… I really wish I knew what was causing this.
For my full config:
Mainboard: i5-1240p
SSD: SN850
RAM: 1 stick of Crucial 16gb RAM as sold by Framework (idk the exact model)
Kernel version: 6.0.8-1 default
I know that openSUSE isn’t an officially supported distro but I’ve seen community posts suggesting that it basically works almost as well as the officially supported distros. And judging by this post, I would guess the issue is not exclusive to openSUSE.
For a visualization of this issue, here is what it looks like. My mouse might be a bit hard to follow but notice how the screen contents briefly shift up vertically after every freeze.
HI there,
I just saw this thread. I posted similar issue with kernel 6.0 in another thread about testing 6.0 kernel.
I have now gave up using anything else than 5.15 kernel.
The latest kernel 6.0.8 doesn t give graphic glitch on my ubuntu 22.04 but it seems to increase my chargee loop bug.
What I had with previous 6.0 kernels was 4 lines of white pixels flickering at the top of the screen continually
@Geoff_Sanderson Does anything show up in dmesg that seems relevant immediately after this happening? If not, please try journalctl --since="10 minutes ago" (especially if you have to reboot).
@Iann_C Same, please try running journalctl --since="10 minutes ago" (especially if you have to reboot).
Whatever is happening will hopefully appear there.
Has anyone found a pattern regarding the fainbow flickering of the first five pixel rows yet? Neither journalctl nor dmesg seem to notice them happening on my end.
1240P and Fedora 37, everything updated if that matters.
I am also having persistent freezing issues on Fedora 37, kernel 6.0.12-300.fc37.x86_64.
Edit: 12th ed Framework with an 850, also.
There are intermittent temporary freezes in any application.
It also can’t go more than ten minutes screensharing through the Zoom (flatpack) app or Discord webapp (app not installed) without freezing permanently (requiring a hard reboot).
Its only my display that freezes - people have reported to me seeing keystrokes go through on the screenshare, and things I’ve typed after freezing have been recovered via autosave after the power cycle.
Additionally, a Ubuntu Boxes VM caused freezing once.
At this point, I am planning to trade out my Fedora installation for Ubuntu. The application support is better e.g. native MCUXpresso packages. Fingers crossed that the freezing issue isn’t present.
Reports of Zoom, Discord webapp (installed or browser tab?), Ubuntu Boxes VM issues causing freezing.
Wayland (default) also tested by logging out and try and trying X? I noted one report with X, so I wanted to see if there are any others.
All effected, please list your Framework as 11th or 12th gen, kernel version, display server. Also, please indicate if there are external monitors attached (especially for those with flickering).
Please use the dash key for “bullet points” so this can be made easy to read as everyone reports in. Also we want short, direct responses so I am not lost in a “wall of text” - my goal is to replicate and then report this to our Fedora contact.
Please just reply on this comment and I’ll see if I can find a common thread.
Running Default Fedora 37 Gnome on i7-1260p Wayland 6.0.12 or latest available ( i915.enable_guc=3 is enabled in kernel parameter, along with the recommended blacklist), 2 1920x1280 external displays attached by dock, Experimental Scaling enabled at 125% for internal display. Roughly one hard freeze per week (enabled guc and huc recently testing to see if things improve), always occuring immediately after coming out of suspend, using a bluetooth mouse, while going into settings.
I have not had the time to go digging, but as soon as this occurs and I have time to debug everything it will likely be a Wayland/Xwayland/Mutter/App being used issue and no longer just an Intel Graphics issue.
The last time I had any freeze it was Firefox rather how it’s hardware acceleration was active. gfx.webrender.all was not enabled and media.ffmpeg.vaapi.enabled were not enabled. Once I activated both I no longer had issues on that front. It was interesting because only the internal monitor was frozen, the Firefox window would minimize to the dash. This behavior is to be expected with Wayland as each window is isolated, however it made me wonder if all the other times I thought I had a hard freeze it was simply Wayland dying on a single window.
(Note: enabling guc and huc has gotten rid of all visual artifacts during screen lock or suspend that I was experiencing previously i.e. a number of red and white lines across the middle of the screen right before it blacked out. Also everything seems more graphically responsive than before, unsure how to describe it. Temps have dropped also while running videos. I will be testing this out on discord and zoom tomorrow, and report back.)
P.S. @Matt_Hartley I am unsrue how you want these things formatted, so an example would be helpful. Thanks.
Thanks. This came close to freezing my stuff up. It got stuck for a moment and then acted buggy afterwards for a bit. Nice to add another item to avoid.
Out of curiosity, which bios version are you running? The issue in this thread seems limited to Intel 12th gen, and we’re running either v3.04 or v3.05 depending on the batch.
On my end it’s bios v3.05. I think @Matt_Hartley mentioned in another thread that all of his test devices are running v3.04.
@Jan-Markus_Bernges I am on Bios 3.05. That being said I don’t think any of these issues are firmware based (others are, but the freezing no). Most of them are definitely a combination of the graphics stack, the desktop environment, and the applications in questions. I definitely think scaling may be part of it or exacerbating the issue, but like many others the resolutoin on the laptop is unusable without it (I did not pay what I did to have a glorified 1366x768 screen). This will just add incentive to get these things worked out. They have already improved over the last month I have had mine. More improvements to go. This is the first week I have not had a hard freeze, and I have been trying. The closest I got was with the nightlight (which I don’t use anyway, so no loss for me there).
The BIOS is deifintiely at fault for some chargng misbehavior, and thundebolt detection issues.
Spoke with my contact with Fedora (works for Red Hat).
He indicated that the freezing is a known issue that has proven difficult to replicate with Fedora and other distros as well. So we’re working on it, but at this point, the best thing we can do is:
Keep updating. My hope is they’ll have an idea what is going on soon.
For any tweaks you make, please make a note in case a fix comes along and these tweaks (kernel parameters for example) end up breaking any potential fixes later on).
@Jan-Markus_Bernges on Fedora 37 with kernel 6.0.13 the nightlight issue is gone, at least in Wayland. This is with no kernel parameters outside of those normal to a Fedora 37 installation and the blacklist for the light sensor.
@nadb Congrats! Would you mind checking if the nightlight flickering still happens directly after boot though?
For me on 6.0.13 turning nightlight on and of some time after boot doesn’t cause the flickering, but still triggers it for the first few minutes after boot.
The only kernel parameters on my side are the light sensor thing and the nvme.noacpi=1 from the linux battery tuning thread.
Your right, same here. Right after boot it still does it. Regardless an improvement, it was doing it before no matter when I tried it. Still not sure what is causing it or even what to look for in logs.
For me when turning on the night light feature it does its thing and then there is odd flickering almost like a frame drop. Then it settles down, and then it acts up again when you turn it off for about a minute afterwards.
Fedora 37 just got an update to kernel 6.0.14 and an intel-gpu-firmware. The night light issue is now gone immediately following boot as well. Also seeing a lot fewer gnome-shell errors in journalctl (referring to a variety of previously spammed messages). Will monitor this last and see if this continues.