Created attachment 1866656 [details] kernel log 1. Please describe the problem: Testing Fedora on the X1 Carbon 10 and I'm seeing significant screen tearing. This can be fixed by disabling psr (i915.enable_psr=0) but the Alderlake-P step C0 CPU I'm using should support PSR. What is particularly strange is that I'm not seeing this issue on Ubuntu when running exactly the same (5.17-rc5) kernel. I took the same source code and compiled it for both (make bindeb-pkg & make binrpm-pkg). I've checked the boot arguments and those don't seem to help. I instrumented the kernel and confirmed that PSR2 is getting enabled in both I've confirmed the same Intel FW is being used in both. I'm stumped as to what it could be. 2. What is the Version-Release number of the kernel: 5.17-rc5 (see the problem with rc7, and the standard Fedora release kernels for F35 and F36 beta too) 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 : No 4. Can you reproduce this issue? If so, please provide the steps to reproduce the issue below: Yes. Install Fedora and boot. The problem is also seen on X1 Yoga 7 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``: Haven't tried the rawhide kernel yet - but tried Linus's 5.17-rc7 so it seems of limited value 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.
[root@x1carbon10 banther]# cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink support: yes [0x03] PSR mode: PSR2 enabled Source PSR ctl: enabled [0x80000299] Source PSR status: SLEEP [0x30000112] Busy frontbuffer bits: 0x00000000 Frame: PSR2 SU blocks: 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 PSR2 selective fetch: enabled As a note, ubuntu has the same except Source PSR ctl: enabled [0x80000236] Source PSR status: SLEEP [0x30000100]
Confirmed that falling back to PSR1 mode means I don't see the problem [root@x1carbon10 0]# echo 3 > i915_edp_psr_debug [root@x1carbon10 0]# cat /sys/kernel/debug/dri/0/i915_edp_psr_status Sink support: yes [0x03] PSR mode: PSR1 enabled Source PSR ctl: enabled [0x81f00ee9] Source PSR status: IDLE [0x04060005] Busy frontbuffer bits: 0x00000000
Created attachment 1866658 [details] Drm.debug=0x16 dmesg log
Created attachment 1866659 [details] drm.debg=0x16 dmesg log
Disabling selective fetch (i915.enable_psr2_sel_fetch=0) - can't reproduce the issue Using i915.psr_safest_params=1 - can still reproduce the issue
There is a mistake in comment #1 The Ubuntu PSR status should be Source PSR status: DEEP_SLEEP [0x80000100] Just in case that's important
Maybe we need to something similar to: * Tue Feb 08 2022 Justin M. Forbes <jforbes> [5.16.8-0] - drm/i915/psr: Disable PSR2 selective fetch for all TGL steps (Lyude Paul) On Alderlake? Lyude any advice here?
It looks like the upstream i915 devs are also working on this. Mark can you build a kernel with this patch and give that a try? : https://patchwork.freedesktop.org/patch/478922/
Thanks Hans, Definitely will do - will update ASAP. As a note - I have a separate email thread going with Lyude (hence where all the above logs come from :)) Mark
Patch didn't help - I tried bumping up the timeout (for the heck of it) and that didn't help either. Mark
(In reply to Hans de Goede from comment #7) > Maybe we need to something similar to: > > * Tue Feb 08 2022 Justin M. Forbes <jforbes> [5.16.8-0] > - drm/i915/psr: Disable PSR2 selective fetch for all TGL steps (Lyude Paul) > > On Alderlake? > > Lyude any advice here? Sigh, that makes the fourth generation PSR has been broken on at some point very early on, really wish Intel could get better at this (I don't know what they could improve on, besides maybe not enabling PSR by default every generation until they've actually tried things with real machines). I will likely come up with a patch tomorrow to disable PSR entirely on Alderlake for the time being on Fedora until Intel actually verifies that PSR is fixed, since it's clearly not actually ready yet to be turned on. JFYI - that's the same thing we had to do for tigerlake which regressed upstream (post-hw release :|) because Intel turned on selective fetch on Tigerlake. Hence that PSR patch you found. Leaving NEEDINFO In case I get sidetracked with this
Thanks Lyude, Having it disabled in Fedora will be good (it will allow us to to the Fedora preload) but I'm really puzzled why it works with exactly the same kernel on Ubuntu. Is the fact that the Source PSR ctl bitmap is different a clue? I started poking at that but haven't really had much time today to get my head around it. Mark
(In reply to Mark Pearson from comment #10) > Patch didn't help - I tried bumping up the timeout (for the heck of it) and > that didn't help either. > Mark Thank you for testing, can you let the upstream i915 devs know that their "hack" does not work. E.g. save the patch as mbox from: https://patchwork.freedesktop.org/patch/478922/ open it in your email ckient and then do a reply ? (In reply to Lyude from comment #11) > I will > likely come up with a patch tomorrow to disable PSR entirely on Alderlake > for the time being on Fedora until Intel actually verifies that PSR is > fixed, since it's clearly not actually ready yet to be turned on. I agree, thanks.
Cool! I didn't know you could do that (I've always wondered how I would join in a thread midway for lists I'm not subscribed to) I've sent a reply - I assume it might get rejected as I'm not subscribed but at least the original poster should see it Thanks! Mark
(In reply to Mark Pearson from comment #14) > Cool! I didn't know you could do that (I've always wondered how I would join > in a thread midway for lists I'm not subscribed to) > > I've sent a reply - I assume it might get rejected as I'm not subscribed but > at least the original poster should see it > > Thanks! > Mark FWIW - I usually keep myself subscribed to lists like this and just use a gmail filter forward all of the emails from the list into a separate folder in my inbox if there's too many emails for me to actually go through. Usually helps to avoid this sort of issue
Also FWIW (In reply to Mark Pearson from comment #14) > Cool! I didn't know you could do that (I've always wondered how I would join > in a thread midway for lists I'm not subscribed to) Note you can do this with almost all kernel lists by finding the email on: https://lore.kernel.org/ And then click on the "raw" link to get a version of the email which you can open your email-client. > I've sent a reply - I assume it might get rejected as I'm not subscribed but > at least the original poster should see it I'm pretty sure the intel-gfx list is open to emails from non-subscribers, almost all kernel mailinglists are open for non-subscribers.
Great tips - thanks! (and yes, my intel-gfx email went thru - that patch isn't related to the PSR2 issue I'm afraid) > FWIW - I usually keep myself subscribed to lists like this and just use a gmail filter forward all of the emails from the list into a separate folder in my inbox if there's too many emails for me to actually go through. Usually helps to avoid this sort of issue So completely off topic from this PSR issue - but I have a lot of pain around email and filters: I use my markpearson email address for mailing lists because it points at a special server in Lenovo that has IMAP support - so I can use an email client that allows me to compose text emails and allows me to use git-email. So far so good. But - Lenovo uses the absolutely awful (and I'm being polite) safelinks feature. It mangles any links it finds and most mailing lists seem to have a URL somewhere in there. You can use add-ons to demangle the links which helps for readability - but it does it *after* the filters are run. I usually filter for my name and keywords "Lenovo" or "lenovo" to catch things that might be interesting/useful or need looking at. The safelinks feature adds 'markpearson' to any link it mangles which then completely messes up my filters. I've somewhat worked around it but my filters are not great and I am convinced I miss a lot of important messages. Lenovo IT also regularly mess up that special server for a few days which is annoying. I'm genuinely considering moving to a non-lenovo account (was looking at protonmail) for anything I do in the community - I'm just trying to psych myself up to do that transition... Mark
(In reply to Mark Pearson from comment #17) > Great tips - thanks! (and yes, my intel-gfx email went thru - that patch > isn't related to the PSR2 issue I'm afraid) > > > FWIW - I usually keep myself subscribed to lists like this and just use a gmail filter forward all of the emails from the list into a separate folder in my inbox if there's too many emails for me to actually go through. Usually helps to avoid this sort of issue > > So completely off topic from this PSR issue - but I have a lot of pain > around email and filters: > > I use my markpearson email address for mailing lists because it > points at a special server in Lenovo that has IMAP support - so I can use an > email client that allows me to compose text emails and allows me to use > git-email. So far so good. > But - Lenovo uses the absolutely awful (and I'm being polite) safelinks > feature. It mangles any links it finds and most mailing lists seem to have a > URL somewhere in there. > You can use add-ons to demangle the links which helps for readability - but > it does it *after* the filters are run. honestly at that point I'd just start using my personal email, and tell your IT that if they don't like that they're welcome to come up with a solution that lets people get their work done. > > I usually filter for my name and keywords "Lenovo" or "lenovo" to catch > things that might be interesting/useful or need looking at. The safelinks > feature adds 'markpearson' to any link it mangles which then > completely messes up my filters. I've somewhat worked around it but my > filters are not great and I am convinced I miss a lot of important messages. > Lenovo IT also regularly mess up that special server for a few days which is > annoying. > I'm genuinely considering moving to a non-lenovo account (was looking at > protonmail) for anything I do in the community - I'm just trying to psych > myself up to do that transition... > > Mark Anyway - one thing I realized we didn't check, did you look to see if the firmware versions for the GuC/HuC (not sure if HuC applies here?) are the same between ubuntu and fedora?
Looks the same to me: Ubuntu: [ 2.375159] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/adlp_dmc_ver2_14.bin (v2.14) [ 2.401052] i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_62.0.3.bin version 62.0 submission:enabled [ 2.401055] i915 0000:00:02.0: [drm] GuC SLPC: enabled [ 2.401056] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9 authenticated:yes [ 2.401294] i915 0000:00:02.0: [drm] GuC RC: enabled Fedora: [ 3.681360] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/adlp_dmc_ver2_14.bin (v2.14) [ 3.728591] i915 0000:00:02.0: [drm] GuC firmware i915/adlp_guc_62.0.3.bin version 62.0 submission:enabled [ 3.728594] i915 0000:00:02.0: [drm] GuC SLPC: enabled [ 3.728595] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9 authenticated:yes [ 3.728959] i915 0000:00:02.0: [drm] GuC RC: enabled
Bug cleanup... Upstream ticket was https://gitlab.freedesktop.org/drm/intel/-/issues/5440 patches to fix this are: https://gitlab.freedesktop.org/drm/intel/-/issues/5440 However - they don't backport cleanly to 5.18 (or at least are beyond my capabilities) so we've disabled PSR2 selective fetch in Fedora for 5.17 & 5.18 and the above fixes should land in 5.19. Closing bug as I think eveything is in place. Thanks to all who helped with this one :)