Created attachment 145375 [details] 9570 EDID info Since PSR was enabled in i915 somewhere around Linux 5.0, my Dell XPS 15 9570 (i7-8750H) experiences very frequent graphical glitches (FIFO underruns), even on drm-tip. I can easily reproduce the glitches 100% of the time, since there is always a glitch when gnome shell starts. The dp_retry_max_vs_optim branch from https://github.com/vsyrjala/linux.git doesn't fix the issue. However, the glitches are completely fixed by passing i915.enable_psr=0 on the kernel command line. I've attached my EDID info.
Can you please attach the dmesg (drmtip) from boot with kernel parameters drm.debug=0x1e log_buf_len=4M. Attach the logs in both the cases, with PSR enabled (where issue happens) and with i915.enable_psr=0 (issue doesn't occur).
Created attachment 145388 [details] drm-tip at 72e400c2b824ab108907631fcf896d3d2020e7d5 with PSR enabled
Created attachment 145389 [details] dmesg of drm-tip at 72e400c2b824ab108907631fcf896d3d2020e7d5 with PSR enabled
Created attachment 145390 [details] dmesg of drm-tip at 72e400c2b824ab108907631fcf896d3d2020e7d5 with PSR disabled
Created attachment 145391 [details] video of one graphical glitch that occurs almost 100% of the time when gdm greeter starts This is a video of one kind of graphical glitch that occurs with PSR enabled. I still frequently get other kinds of glitches while using my laptop normally.
Hi Sultan Could you test this? sudo su more /sys/kernel/debug/dri/0/i915_edp_psr_status echo 0x3 > /sys/kernel/debug/dri/0/i915_edp_psr_debug more /sys/kernel/debug/dri/0/i915_edp_psr_status Share the output of the above and let me know if the glitches stops after that(after reboot you need to run that again to enable the hack)
Hi Jose. Forcing PSR1 fixes the glitches. root@sultan-box:/home/sultan# more /sys/kernel/debug/dri/0/i915_edp_psr_status Sink support: yes [0x03] PSR mode: PSR2 enabled Source PSR ctl: enabled [0xc0000216] Source PSR status: DEEP_SLEEP [0x80080130] Busy frontbuffer bits: 0x00000000 Frame: PSR2 SU blocks: 0 0 1 0 2 0 3 0 4 0 5 0 6 0 7 0 root@sultan-box:/home/sultan# echo 0x3 > /sys/kernel/debug/dri/0/i915_edp_psr_debug root@sultan-box:/home/sultan# more /sys/kernel/debug/dri/0/i915_edp_psr_status Sink support: yes [0x03] PSR mode: PSR1 enabled Source PSR ctl: enabled [0x81f00e26] Source PSR status: SRDOFFACK [0xc4040016] Busy frontbuffer bits: 0x00000000 root@sultan-box:/home/sultan#
Created attachment 145437 [details] [review] patch calculating IO buffer wake and fast wake lines Thanks for the test, can you apply the patch attached and try again with PSR2? If that do not work, please revert it and add this kernel parameter: i915.enable_fbc=0 and try again with PSR2. Please let me know the result
The attached patch doesn't fix it. Reverting it and passing i915.enable_fbc=0 doesn't fix it either.
Created attachment 145516 [details] [review] test patch Hi Sultan Can you give a try with this? If it do not work, try to increase: EDP_PSR2_FRAME_BEFORE_SU(2) up to 15.
Hi Jose That patch doesn't work and creates new glitches. However, increasing EDP_PSR2_FRAME_BEFORE_SU to 15 does fixes the glitch shown in my video but it creates even more new glitches.
Created attachment 145607 [details] [review] patch disabling PSR2 in the user panel Hi Sultan So nothing else comes in my mind to test in your panel, looks like it is a batch or model variation problem, so disabling PSR2 in that specific panel is the only solution. Could you test this patch before I send it upstream? Thanks
Created attachment 145653 [details] [review] fixed patch to disable PSR2 for the affected panel Hi Jose, Your patch didn't work, so I fixed it up (see attached). Please review it and let me know if it looks correct. Also, how were you trying to reproduce this on the panel you have on your desk? Could I know your setup?
Created attachment 145654 [details] [review] fixed patch to disable PSR2 for the affected panel Oops, uploaded the wrong patch earlier. Here's the correct one.
(In reply to Sultan Alsawaf from comment #13) > Created attachment 145653 [details] [review] [review] > fixed patch to disable PSR2 for the affected panel > > Hi Jose, > > Your patch didn't work, so I fixed it up (see attached). Please review it > and let me know if it looks correct. Compared your patch with mine, the result of both should be the same, did you spot any difference? I'm sure that other developers will not like this manual string comparison too. > > Also, how were you trying to reproduce this on the panel you have on your > desk? Could I know your setup? Running Ubuntu 18.10 with drm-tip kernel on a Whiskey Lake reference platform, all GEN9 are very similar on display so I should be able to reproduce it if I had the exactly same panel model as you.
> Compared your patch with mine, the result of both should be the same, did > you spot any difference? > I'm sure that other developers will not like this manual string comparison > too. It's not the same because your patch does not adhere to the EDID specification. According to the EDID standard (https://en.wikipedia.org/wiki/Extended_Display_Identification_Data#Display_Descriptors), the 13 bytes of text for the display descriptor are terminated with a line feed character when the length of the content is less than 13 bytes (it's not terminated with a zero byte, which is what your strncmp assumes). My panel model string is less than 13 bytes ("TK6R7"), but my EDID is malformed and the model string is terminated with a 0x80 character. So in my patch, I made panel_in_psr2_blacklist() interpret any !isgraph character as a terminating character, which is what the edid-decode tool does as well. Here's the raw dump of my EDID for you to see: 00000000: 00 ff ff ff ff ff ff 00 4d 10 9a 14 00 00 00 00 ........M....... 00000010: 04 1c 01 04 a5 22 13 78 0e de 50 a3 54 4c 99 26 .....".x..P.TL.& 00000020: 0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 .PT............. 00000030: 01 01 01 01 01 01 ac 37 80 a0 70 38 3e 40 30 20 .......7..p8>@0 00000040: 35 00 58 c2 10 00 00 18 00 00 00 00 00 00 00 00 5.X............. 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 fe 00 54 ...............T 00000060: 4b 36 52 37 80 4c 51 31 35 36 4d 31 00 00 00 00 K6R7.LQ156M1.... 00000070: 00 02 41 03 28 00 12 00 00 0a 01 0a 20 20 00 2b ..A.(....... .+ > Running Ubuntu 18.10 with drm-tip kernel on a Whiskey Lake reference > platform, all GEN9 are very similar on display so I should be able to > reproduce it if I had the exactly same panel model as you. I'm running Ubuntu 19.10 with drm-tip. Try using that, and then change the login screen background to make the glitch much easier to see. To change the login screen background, run this long command: sudo perl -i -p0e 's,(#lockDialogGroup.*?)},#lockDialogGroup {\nbackground: #2c001e url(file:///usr/share/backgrounds/Staniel_Cay_by_Joseph_Bylund.jpg);\nbackground-repeat: no-repeat;\nbackground-size: cover;\nbackground-position: center;\n},s' /usr/share/gnome-shell/theme/gdm3.css Then keep rebooting until you see the glitch in my video, assuming your setup is affected.
Created attachment 145743 [details] Decoded XPS 13 7390 FHD panel EDID I have the exactly the same issue on a Dell XPS 13 7390 (non-convertible). PSR1 is stable, PSR2 is glitchy. The panel EDID is attached. Maybe this is a Dell-specific firmware issue, as the panel is quite different?
My XPS 13 9380 is affected by this issue as well, despite having the latest LCD firmware from Dell which claims to fix PSR glitches in Windows (https://www.dell.com/support/home/us/en/04/drivers/driversdetails?driverid=tcnc2&oscode=wt64a&productcode=xps-13-9380-laptop).
Since apparently multiple machine with various different panels are affected, maybe it makes sense to add a driver option to disable PSR2? The easiest way could be to change semantics of enable_psr. E.g. let enable_psr=2 only use PSR1. PSR results in great power saving, so we shouldn't need to disable it completely.
Sultan Alsawaf the glitch only happens when GDM shows up on both of your machines? Grigori Goronzy the issue also only happens on GDM for you too? can you upload dmesg with drm.debug=0x1e using drm-tip, just to make sure nothing else is wrong?
Jose, the glitches occur randomly all the time (GDM is just a good reproducer). On the XPS 13 9380 I'm not even using GDM and it experiences the glitches.
No, the issue happens randomly in a standard GNOME session, as far as I remember with both Wayland and X.
Hi Sultan and Grigori Can you give a try with this branch? https://github.com/zehortigoza/linux/tree/psr-test Then please share the logs Thanks
Jose, The psr-test branch fixes the glitch in my video, but I still get random glitches after using my machine for a few minutes. I see from your GitHub profile that you are also in Portland. If you'd like, we can meet up so you can test on my laptop directly.
(In reply to Sultan Alsawaf from comment #24) > Jose, > > The psr-test branch fixes the glitch in my video, but I still get random By the first part you mean it fixed the glitch you had on gdm? > glitches after using my machine for a few minutes. Can you explain how is this glitches that are still happening? > > I see from your GitHub profile that you are also in Portland. If you'd like, > we can meet up so you can test on my laptop directly. Thanks so much for testing, also could you share the dmesg right after ones of those glitches happens? Thanks
(In reply to Jose Roberto de Souza from comment #25) > > glitches after using my machine for a few minutes. > > Can you explain how is this glitches that are still happening? I just opened Chromium and shortly after it opened, the bottom half of the screen glitched for a split second. Also, when I am typing these comments on Bugzilla, sometimes the word I am typing disappears for a split second. > Thanks so much for testing, also could you share the dmesg right after ones > of those glitches happens? There is nothing in dmesg when the glitches occur. Also, I have noticed that even with PSR2 disabled, I still see some rare glitches with only PSR1 enabled on both of my laptops. For example, I wake my XPS 13 from suspend, the image on the screen shakes briefly. Also, when I am using Chromium, part of the screen flickers sometimes. These issues don't happen when PSR is disabled completely.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/intel/issues/425.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.