Created attachment 141608 [details] dmesg with drm.debug=0x1e log_buf_len=1M System environment: -- chipset: KabyLake Refresh -- system architecture: 64-bit -- xf86-video-intel: -- xserver: 1.20.1 -- mesa: 18.2 -- libdrm: 2.4.93 -- kernel: drm-tip (commit 0875e7885717d3d812941e8e2db1dc99728be1ff) -- Linux distribution: Fedora 29 Beta (and Fedora 28) -- Machine or mobo model: Dell Latitude 7490 -- Display connector: eDP Reproducing steps: Setup full disk encryption with LUKS/dm-crypt. Use Plymouth[1] to provide a graphical interface for entering in the decryption password. This is bundled as part of the distribution since Fedora 10 and setup automatically. Enable PSR via i915.enable_psr=1. I have confirmed there are no issues with psr disabled. While typing in the password, or otherwise updating the screen there is graphical corruption, like grey static that will intermittently cover portions of the screen. If I do not cause the screen to update, e.g. just wait there at the Plymouth lock screen, there is no graphical corruption. Once I am past Plymouth and into the login manager/desktop there are no video/display problems at all. [1] https://cgit.freedesktop.org/plymouth/ Additional info: Because this occurs so early at boot I think this must be either a quirk with my hardware, a PSR oddity, or a problem with Plymouth. See attached files. Please let me know if you would like further information or clarification.
Created attachment 141609 [details] HUC status
Created attachment 141610 [details] GUC status
Created attachment 141611 [details] PSR status
Created attachment 141612 [details] lspci -vvv
Created attachment 141613 [details] Display info
Created attachment 141614 [details] Kernel config
I should have been more clear about the chipset, it's an Intel UHD 620. Thanks for your time.
Tom, to understand the bug better.. As a user you see graphical corruption only while entering password or when updating the screen (mouse or keyboard actions). Otherwise everything seems to normal, right? How often it is reproducible? Can you try to reproduce this issue with latest drm-tip? (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot.
Tom, can you provide requested information, this is needed for investigation.
Apologies for the delay, I was on vacation. I can no longer reproduce this on a fresh Fedora install on my laptop, so I think the problem was not with the intel graphics driver.
Works as expected. Closing this bug.
Created attachment 143211 [details] drm.debug=0x1e log_buf_len=4M
Created attachment 143212 [details] PSR Status
Created attachment 143213 [details] Kernel config for drm-tip
Created attachment 143214 [details] i915_display_info
Reopening, as this same issue has cropped up again on Fedora 29 after upgrading the (stock Fedora) kernel from 4.19.5 to 4.20.3. I've reproduced the issue with drm-tip (commit 198addb18e12d2469bc41d57f9ed63e1072a7f82) and uploaded a new dmesg with drm.debug=0x1e log_buf_len=4M as previously requested. Here is a (poor quality) video of the issue: https://drive.google.com/file/d/12IgXOLrOKdFfoolbml6B6Pv5Y_ueS0gB/view Let me know if you need any additional information, and thanks for your time.
Potential workaround found: Setting the kernel parameter i915.fastboot=1 (with i915.enable_psr=1) results in no screen corruption in plymouth's LUKS prompt. This appears to be effective on both drm-tip and Fedora 29's 4.20.x kernel. This issue was reproducible on every boot, and so far I cannot reproduce the screen corruption with fastboot enabled after 10+ boot cycles. Any idea why fastboot has an effect on this? I know that fastboot is likely to be set by default on SKL+ in the next kernel release, but it's still a bit strange that there's some interaction between psr and fastboot being disabled.
(In reply to Tom Seewald from comment #17) > Potential workaround found: > > Setting the kernel parameter i915.fastboot=1 (with i915.enable_psr=1) > results in no screen corruption in plymouth's LUKS prompt. This appears to > be effective on both drm-tip and Fedora 29's 4.20.x kernel. This issue was > reproducible on every boot, and so far I cannot reproduce the screen > corruption with fastboot enabled after 10+ boot cycles. > > Any idea why fastboot has an effect on this? I know that fastboot is likely > to be set by default on SKL+ in the next kernel release, but it's still a > bit strange that there's some interaction between psr and fastboot being > disabled. BIOS disables PSR, my guess is that fastboot inherits that state. A quick way to verify would be to check i915_edp_psr_status or dmesg with drm.debug=14 at Plymouth's login. And compare this to a boot without i915.fastboot=1. Can you please attach dmesg for the both test cases? Btw, you shouldn't be needing i915.enable_psr=1 on drm-tip. PSR should be enabled by default on a KBL refresh.
(In reply to Dhinakaran Pandiyan from comment #18) A quick > way to verify would be to check i915_edp_psr_status or dmesg with > drm.debug=14 at Plymouth's login. And compare this to a boot without > i915.fastboot=1. Can you please attach dmesg for the both test cases? What is the best way/is it possible to capture dmesg and check /sys/kernel/debug/dri/ values at the Plymouth LUKS prompt? This is relatively early in the boot process, before I have entered in the decryption password for my drive. I have verified however, that after the boot process has completed psr appears to be enabled both with fastboot on and off. > Btw, you shouldn't be needing i915.enable_psr=1 on drm-tip. PSR should be > enabled by default on a KBL refresh. Thanks, I can confirm that on drm-tip without explicitly setting i915.enable_psr=1 I have graphical corruption while typing in my LUKS password at the plymouth prompt.
Created attachment 143271 [details] PSR after boot with fastboot disabled
Created attachment 143272 [details] PSR after boot with fastboot enabled
Friendly update, this is still reproducible on drm-tip as of commit 22cdf0031c984a211ed9edac3979d0156737972d.
Hi Tom Seewald There is a easy way to reproduce and debug this issue without having to encrypted disk and keep rebooting? I did this: sudo ./plymouthd sudo ./plymouth show-splash sudo ./plymouth ask-for-password And it works fine.
(In reply to Tom Seewald from comment #22) > Friendly update, this is still reproducible on drm-tip as of commit > 22cdf0031c984a211ed9edac3979d0156737972d. Even with fastboot enabled?
(In reply to Jose Roberto de Souza from comment #24) > (In reply to Tom Seewald from comment #22) > > Friendly update, this is still reproducible on drm-tip as of commit > > 22cdf0031c984a211ed9edac3979d0156737972d. > > Even with fastboot enabled? No, only with fastboot disabled. It seems like this is only an issue while the system is booting.
Now that fastboot is enabled by default on SKL+, is this still be considered a supported configuration? If not, I'll close it.
As the issue is still valid keep it open but as it is not reproducible with the default parameters we should lower the importance to low or lowest, James?
Jose - that sounds reasonable to me. Tom - just to verify, if you take drm-tip today and boot without modifying the fastboot or psr parameter, you do not see this problem, correct?
(In reply to James Ausmus from comment #28) > Tom - just to verify, if you take drm-tip today and boot without modifying > the fastboot or psr parameter, you do not see this problem, correct? Yes I just built drm-tip (79df6ae8e7d6), booted it with *no* custom i915 kernel parameters set, and confirmed that there is no graphical corruption during the Plymouth LUKS prompt.
You are reporter of the issue currently having low priority. Do you still see issue. If so, please spesify clearly what is impact to you.
(In reply to Jani Saarinen from comment #30) > You are reporter of the issue currently having low priority. Do you still > see issue. If so, please spesify clearly what is impact to you. Yes, on my Dell Latitude 7490, running Fedora 31, there is graphical corruption when entering in my decryption password after rebooting the system. However, if I instead do a cold boot, there is no corruption when entering in my decryption password on the plymouth screen. I wonder if this is related to this report [1]. [1] https://bugs.freedesktop.org/show_bug.cgi?id=112253
-- 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/157.
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.