1. Please describe the problem: When running 6.19.rc8 and also the 6.19 final on F44 the graphics breaks (running GNOME), when moving with mouse cursor and also when i.e. selecting the container in Ptyxis making the machine unusable (I can attach a video if needed). Otherwise if using keyboard only, then things sort of work. Doing i915.enable_psr=0 fixes the problem altogether. What fixes the issue is also using the 6.18 kernel from F43 2. What is the Version-Release number of the kernel: kernel-6.19.0-0.rc8.54.fc44.x86_64 kernel-6.19.0-59.fc44 3. Did it work previously in Fedora? If so, what kernel version did the issue *first* appear? Old kernels are available for download at https://koji.fedoraproject.org/koji/packageinfo?packageID=8 : Between 6.18 and 6.19 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: On my hardware which is a Lenovo P14s G5 laptop with Intel Ultra 7 165H (Meteor Lake) and 3K display it is enough to boot 6.19 kernel 5. Does this problem occur with the latest Rawhide kernel? To install the Rawhide kernel, run ``sudo dnf install fedora-repos-rawhide`` followed by ``sudo dnf update --enablerepo=rawhide kernel``: Yes, it does. 6. Are you running any modules that not shipped with directly Fedora's kernel?: No. 7. Please attach the kernel logs. You can get the complete kernel log for a boot with ``journalctl --no-hostname -k > dmesg.txt``. If the issue occurred on a previous boot, use the journalctl ``-b`` flag. Reproducible: Always
Proposed as a Blocker for 44-beta by Fedora user tpopela using the blocker tracking app because: The laptop can't be normally used with the default configuration unless Intel's Panel Self Refresh is disabled.
Created attachment 2128874 [details] kernel log
Same here. On the latest Kernel 6.19, graphical issues such as screen tearing and stuttering appear immediately after booting into GNOME. Everything works fine on 6.18. More precisely, this problem started with Kernel 6.19 RC2 and is still present in the stable release. After testing with i915.enable_psr=0, the issue indeed disappears. ThinkPad P14s, Intel U285H.
+5 in https://pagure.io/fedora-qa/blocker-review/issue/2028 , marking accepted.
Has anyone given a rawhide kernel a test to see if the issue was fixed with the drm pull?
I've tried kernel-6.20.0-0.rc0.260217g9702969978695.10.fc45 and it is still broken.
Tomas, are you willing to bisect the kernel to figure out the commit that broke it?
No, I don't have the capacity to do so.
Tomas, uploading a short video would be nice, so that people have a good idea of how it looks like. We've tested our QA laptops and unfortunately none of them seem to exhibit this bug.
Similar but not the same (might be related, though) - bug 2441941
> Tomas, uploading a short video would be nice, so that people have a good idea of how it looks like. You internally have the access (at least Petr) to the recordings, feel free to upload it somewhere and share it here.
Created attachment 2130700 [details] flickering example video
Hum, has anyone seen this on anything other than a P14s ? I kinda had the impression it was known to affect a wide range of systems, but if it's just one, it might not be a Beta blocker really...
Hi, I conducted a test on another Chromebook of mine, also running Fedora 43 with an Intel CPU and integrated GPU. I installed and tested Kernel 6.19.3 and did not encounter any PSR-related issues. Kernel:https://koji.fedoraproject.org/koji/buildinfo?buildID=2944717 CPU:Intel Celeron 6305 GPU:Intel UHD G4(TGL GT2) However, it's currently difficult to determine whether this issue is specific to the P14, or to certain ThinkPad models. Have any users with Intel MTL or ARL performed tests? I personally suspect this might be specific to MTL/ARL GPUs.Intel has had some commits with bugs in both 6.18 and 6.19; 6.18 even caused some Sycl-related issues that were only fixed later. If this is specific to certain ThinkPad models... I know there's someone named Mark Pearson who should be responsible for Lenovo product Linux support. I wonder if we could seek his help, since ThinkPads also come with Fedora pre-installed and will inevitably encounter Kernel 6.19-related issues. From what I recall, I installed and tested Kernel 6.19 back when it was still at RC1, and I encountered this issue at that time. I suspect that something in the DRM/next or similar PRs after the 6.19 Merge Window opened may have caused this situation.
Hi @plumis, >> Have any users with Intel MTL or ARL performed tests? I have no issues with Version: ThinkPad P1 Gen 7 + lspci -k | grep -A 3 -i "VGA\|3D" 00:02.0 VGA compatible controller: Intel Corporation Meteor Lake-P [Intel Arc Graphics] (rev 08) Subsystem: Lenovo Device 2235 Kernel driver in use: i915 Kernel modules: i915, xe kernel-6.19.3-300.fc44.x86_64 mesa-dri-drivers-25.3.5-2.fc44.x86_64 --- It would also be great if anyone affected can try past kernel builds from https://koji.fedoraproject.org/koji/packageinfo?packageID=8 and identify the last working one and the first broken one.
Thank you very much for your testing. It seems the issue is becoming even more complex. I have tested several devices I have on hand, all running a consistent environment: Fedora 43 + Intel GPU + Kernel 6.19.3. The results are as follows: - Chromebook (Intel Celeron 6305): Normal - Surface Go 2 (Intel Core m3-8100Y / 4454Y): Normal - ThinkPad P14s Gen 6: Faulty (exhibits the same tearing/stuttering) Combined with the original reporter Tomas’s ThinkPad P14s Gen 5, it appears that this issue specifically affects the base-model ThinkPad P14s series with Intel graphics. Since the Gen 6 and Gen 5 are minor iterations of each other, I suspect this might be related to the Display Panel. For reference, my screen is a 3K (3072 x 1920) IPS panel. I am not sure if Tomas has the exact same panel configuration. I also attempted the following troubleshooting steps, but none of them resolved the issue: - Switching from the i915 driver to the experimental Xe driver. - Toggling Mutter’s VRR (Variable Refresh Rate) settings (both enabling and disabling). - Testing the newly released Kernel 7.0 RC1. I tried to extract useful information from the logs, but unfortunately, they appear silent; there is no mention of PSR or any related errors in the kernel logs (dmesg). I checked Intel PSR commits log and find nothing useful: https://github.com/torvalds/linux/commits/master/drivers/gpu/drm/i915/display/intel_psr.c If this is indeed panel-specific, it is difficult to determine if this is exclusive to the P14s. Lenovo uses this same panel model in many other devices, such as the ThinkBook 14+ and likely in future generations of the P14s as well.
I accidentally tried connecting an external monitor to test, and I made some new discoveries. When I adjust the refresh rate to 60Hz, everything works normally. When I set it back to 120Hz, screen tearing and stuttering occur. Both my P14s and Tomas's P14s display panels should support 120Hz refresh rate, so we have the same problem. Could the reason the P1 Gen 7 has no issues be because its screen refresh rate is 60Hz? So, is one of the reasons for reproducing this issue the high refresh rate? After kernel 6.19, will Intel core laptops using high refresh rate screens encounter screen tearing issues, and can disabling PSR solve it?
> For reference, my screen is a 3K (3072 x 1920) IPS panel. I am not sure if Tomas has the exact same panel configuration. Yes, I do.
https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15771
Want to give https://koji.fedoraproject.org/koji/taskinfo?taskID=142945237 a try? It is a scratch build, so not secure boot signed unfortunately.
(In reply to Justin M. Forbes from comment #20) > Want to give https://koji.fedoraproject.org/koji/taskinfo?taskID=142945237 a > try? It is a scratch build, so not secure boot signed unfortunately. Just tried. Still have issue.
I'm calling for a re-vote on blocker status here, since despite sending out a call for testing we've yet to receive any report that this affects any systems other than P14s with 120Hz display, and there is a clear workaround for it. Based on current information I think it'd be OK to release Beta with this as a documented known issue.
I am all for this being a final blocker, but it seems a bit much making it a beta blocker as a bug impacting limited hardware with a known workaround in my opinion. As there is no upstream fix just yet, the timeframe for a fix in Fedora is still unclear.
During Beta Go/NoGo meeting [1]: !agreed 2438442 - RejectedBlocker (Beta) - this is rejected as we have no clear indication it affects a very wide range of hardware. It's only positively confirmed to affect certain variants of a single laptop model (Thinkpad P14s with 120Hz screen). Per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? our decision is that's not broad enough to merit the bug being a Beta blocker [1] https://meetbot-raw.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-03-05/ Transferring the proposal to a FinalBlocker instead.
https://patchwork.freedesktop.org/series/162864/ here is a patch from intel for testing about fix this issue.
Discussed in a blocker review meeting [1] on 2026-03-09. The outcome was: !agreed 2438442 - RejectedBlocker (Final) - this is rejected per https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local_configuration_dependent_issues? , because so far we still have no indication this affects more than a single laptop model, and blocking the release for a workaroundable issue on a single laptop model isn't really in line with past reality. Note "Bugs that affect only a single adapter or small group of closely-related adapters are almost never taken as blockers" in the FAQ. [1] https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/
https://koji.fedoraproject.org/koji/taskinfo?taskID=143171521 is a build you can test that patch with
(In reply to Justin M. Forbes from comment #27) > https://koji.fedoraproject.org/koji/taskinfo?taskID=143171521 is a build you > can test that patch with Thanks for your building. It seems still havent fix this issue yet. It seems we need to continue communicating with the Intel upstream developers, report the logs, and seek their assistance to resolve this.
In fact, another laptop user with a Lenovo Yoga 7 Pro (Intel) has encountered the same issue, but from openSUSE: https://bugzilla.opensuse.org/show_bug.cgi?id=1259036 It's possible they are using the same LCD panel, a 14.5" 3K (3072x1920) IPS, or possibly the OLED version, but both are 120Hz with VRR, and also on MTL and newer platforms.
If anyone has a SUSE bugzilla account, it'd be great if they could comment there and link to this bug and https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15771 . I have an account for progress.opensuse.org , but apparently it's not the same auth system...
Currently, the OpenSUSE user who reported the issue has already gotten involved on the i915 side: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15771 Based on the current situation, all affected systems share the same 3K IPS display panel and/or high-refresh-rate screens. Intel appears to have narrowed down the root cause to a potential incompatibility between Panel Self-Refresh (PSR) and Variable Refresh Rate (VRR). It's unclear whether this issue is related to the display panel manufacturer or to a conflict between VRR and PSR. Given that GNOME 50 enables VRR support by default, it's possible that other users may be affected as well. Affected users report that the issue disappears after disabling and then re-enabling PSR2: $ echo 1 > /sys/kernel/debug/dri/1/i915_edp_psr_debug # disable PSR $ echo 0 > /sys/kernel/debug/dri/1/i915_edp_psr_debug # re-enable PSR Intel has now provided a new patch for testing (the previous one didn't work). https://patchwork.freedesktop.org/series/162920/ To be honest, I'm not a kernel developer and I'm not very experienced with applying patches and compiling the kernel—I tried several times yesterday but wasn't successful.
(In reply to plumlis from comment #31) > Given that GNOME 50 enables VRR > support by default, it's possible that other users may be affected as well. I don't think that's correct. With Fedora 44 Beta and a VRR display, the VRR option in available by default, but *disabled* by default. Also, the display runs at 60 Hz by default (while my display can do 144 Hz). I need to switch both manually. Tested with a Live image. Also, interestingly, in comment 16 you said that disabling VRR doesn't help (only lowering refresh rate does). So I wonder whether this can really be attributed to VRR and how. But anyway, I just wanted to point out that in a default state, Fedora seems be running with conservative values (60 Hz, no VRR) and changes must be done manually. Unless this is hardware-specific.
(In reply to plumlis from comment #31) > Intel has now provided a new patch for testing (the previous one didn't > work). > > https://patchwork.freedesktop.org/series/162920/ > > To be honest, I'm not a kernel developer and I'm not very experienced with > applying patches and compiling the kernel—I tried several times yesterday > but wasn't successful. I've started the scratch build with that patch in https://koji.fedoraproject.org/koji/taskinfo?taskID=143202465 (it is still building)
Kamil: I wonder if the reason we're not seeing this more is that on *most* systems we default to 60Hz even if the panel is 120Hz-capable, but on the affected systems we default to 120Hz? It's just a theory, but it might explain things.
(In reply to Kamil Páral from comment #32) > With Fedora 44 Beta and a VRR display, the VRR option in available by default, but *disabled* by default. That's right. > Unless this is hardware-specific. It's not. mutter prefers modes which don't allow VRR over the corresponding modes which allow VRR, so the default configuration never allows VRR. Moreover, in the attached video, VRR can't really be active (mutter doesn't enable the VRR_ENABLED CRTC property), even if VRR was enabled in mutter's display configuration, because there's no single surface which covers the display (since the top bar is visible). > So I wonder whether this can really be attributed to VRR and how. It seems unlikely, though it might still be possible in theory, if the kernel driver enables VRR signalling even while the VRR_ENABLED property is disabled (e.g. to avoid glitches when toggling the property, though I thought this could only be necessary in some cases with HDMI display connections, i.e. not with internal panels). Note that in this case mutter couldn't do anything to avoid the issue, per above VRR is effectively disabled in the KMS API in the attached video anyway. However, I don't see any mention of VRR in the referenced gitlab issue or patch series, so it's not clear where the "Intel appears to have narrowed down the root cause to a potential incompatibility between Panel Self-Refresh (PSR) and Variable Refresh Rate (VRR)" statement is coming from.
Hi, English is not my native language, but I will do my best to clearly describe everything I currently know about this issue. > Is this issue related to VRR and Mutter? Initially, Intel engineers did speculate about this possibility, but it now seems to have been ruled out. It is also unrelated to Mutter. It appears to be purely a kernel issue where PSR2 fails to be correctly enabled or disabled under certain specific conditions. > What is the current status/nature of this problem? Current testing indicates that on some 120Hz panels (possibly those with hardware VRR support, though hardware VRR might not even be required), when the refresh rate is set to 120Hz, the Intel driver fails to correctly apply PSR2. This results in screen corruption and stuttering. However, if you manually disable and then re-enable PSR2, the issue disappears. > Why is this issue difficult to detect? If I recall correctly, Fedora (and most GNOME-based distributions) does not enable the 120Hz refresh rate by default after a fresh installation. Therefore, for new installations, even if the hardware has this issue related, users won't encounter the problem until they manually enable 120Hz. In the case of myself and other users who encountered this, we had already manually enabled 120Hz. Everything worked perfectly on kernel 6.18, and the issue only appeared after we upgraded to kernel 6.19. Furthermore, this problem might only occur on 120Hz panels that support VRR in hardware, causing an error during the kernel driver loading phase. However, due to a limited number of test machines, we cannot yet determine exactly which users and hardware configurations are affected.
For the record, a common issue description is here: https://discussion.fedoraproject.org/t/common-issue/182839
This issue is fixed with https://patchwork.freedesktop.org/series/163098/ (verified through https://koji.fedoraproject.org/koji/taskinfo?taskID=143249180 scratch build).
FEDORA-2026-b9bd91408a (kernel-6.19.7-300.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-b9bd91408a
FEDORA-2026-21a28a358f (kernel-6.19.7-100.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2026-21a28a358f
FEDORA-2026-2f3dbc95bc (kernel-6.19.7-200.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-2f3dbc95bc
FEDORA-2026-b9bd91408a has been pushed to the Fedora 44 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-b9bd91408a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-b9bd91408a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-2f3dbc95bc has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-2f3dbc95bc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2f3dbc95bc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-21a28a358f has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-21a28a358f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-21a28a358f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Verified by plumlis here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-2f3dbc95bc#comment-4579734
FEDORA-2026-b9bd91408a (kernel-6.19.7-300.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-2f3dbc95bc (kernel-6.19.7-200.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-21a28a358f (kernel-6.19.7-100.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.