Summary: | Graphical corruption with PSR - affects Plymouth only | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Tom Seewald <tseewald> | ||||||||||||||||||||||||||||
Component: | DRM/Intel | Assignee: | Jose Roberto de Souza <jose.souza> | ||||||||||||||||||||||||||||
Status: | RESOLVED MOVED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||||||||||||||||
Severity: | normal | ||||||||||||||||||||||||||||||
Priority: | low | CC: | intel-gfx-bugs, james.ausmus, jose.souza, lakshminarayana.vudum | ||||||||||||||||||||||||||||
Version: | DRI git | ||||||||||||||||||||||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||||||||||||||||||||||
OS: | Linux (All) | ||||||||||||||||||||||||||||||
Whiteboard: | Triaged, ReadyForDev | ||||||||||||||||||||||||||||||
i915 platform: | KBL | i915 features: | display/PSR | ||||||||||||||||||||||||||||
Attachments: |
|
Description
Tom Seewald
2018-09-18 05:44:12 UTC
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.