Bug 107966 - Graphical corruption with PSR - affects Plymouth only
Summary: Graphical corruption with PSR - affects Plymouth only
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: low normal
Assignee: Jose Roberto de Souza
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2018-09-18 05:44 UTC by Tom Seewald
Modified: 2019-11-29 17:52 UTC (History)
4 users (show)

See Also:
i915 platform: KBL
i915 features: display/PSR


Attachments
dmesg with drm.debug=0x1e log_buf_len=1M (835.89 KB, text/plain)
2018-09-18 05:44 UTC, Tom Seewald
no flags Details
HUC status (206 bytes, text/plain)
2018-09-18 05:44 UTC, Tom Seewald
no flags Details
GUC status (448 bytes, text/plain)
2018-09-18 05:44 UTC, Tom Seewald
no flags Details
PSR status (173 bytes, text/plain)
2018-09-18 05:45 UTC, Tom Seewald
no flags Details
lspci -vvv (39.22 KB, text/plain)
2018-09-18 05:45 UTC, Tom Seewald
no flags Details
Display info (2.08 KB, text/plain)
2018-09-18 05:45 UTC, Tom Seewald
no flags Details
Kernel config (152.01 KB, text/plain)
2018-09-18 05:46 UTC, Tom Seewald
no flags Details
drm.debug=0x1e log_buf_len=4M (678.22 KB, text/plain)
2019-01-23 22:31 UTC, Tom Seewald
no flags Details
PSR Status (156 bytes, text/plain)
2019-01-23 22:35 UTC, Tom Seewald
no flags Details
Kernel config for drm-tip (197.40 KB, text/plain)
2019-01-23 22:35 UTC, Tom Seewald
no flags Details
i915_display_info (1.70 KB, text/plain)
2019-01-23 22:37 UTC, Tom Seewald
no flags Details
PSR after boot with fastboot disabled (158 bytes, text/plain)
2019-02-01 20:49 UTC, Tom Seewald
no flags Details
PSR after boot with fastboot enabled (158 bytes, text/plain)
2019-02-01 20:49 UTC, Tom Seewald
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Seewald 2018-09-18 05:44:12 UTC
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.
Comment 1 Tom Seewald 2018-09-18 05:44:32 UTC
Created attachment 141609 [details]
HUC status
Comment 2 Tom Seewald 2018-09-18 05:44:49 UTC
Created attachment 141610 [details]
GUC status
Comment 3 Tom Seewald 2018-09-18 05:45:03 UTC
Created attachment 141611 [details]
PSR status
Comment 4 Tom Seewald 2018-09-18 05:45:23 UTC
Created attachment 141612 [details]
lspci -vvv
Comment 5 Tom Seewald 2018-09-18 05:45:46 UTC
Created attachment 141613 [details]
Display info
Comment 6 Tom Seewald 2018-09-18 05:46:04 UTC
Created attachment 141614 [details]
Kernel config
Comment 7 Tom Seewald 2018-09-18 05:51:04 UTC
I should have been more clear about the chipset, it's an Intel UHD 620.

Thanks for your time.
Comment 8 Lakshmi 2018-09-20 13:30:39 UTC
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.
Comment 9 Lakshmi 2018-10-11 15:08:44 UTC
Tom, can you provide requested information, this is needed for investigation.
Comment 10 Tom Seewald 2018-10-12 02:05:20 UTC
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.
Comment 11 Lakshmi 2018-10-12 06:52:52 UTC
Works as expected. Closing this bug.
Comment 12 Tom Seewald 2019-01-23 22:31:15 UTC
Created attachment 143211 [details]
drm.debug=0x1e log_buf_len=4M
Comment 13 Tom Seewald 2019-01-23 22:35:00 UTC
Created attachment 143212 [details]
PSR Status
Comment 14 Tom Seewald 2019-01-23 22:35:58 UTC
Created attachment 143213 [details]
Kernel config for drm-tip
Comment 15 Tom Seewald 2019-01-23 22:37:12 UTC
Created attachment 143214 [details]
i915_display_info
Comment 16 Tom Seewald 2019-01-23 22:42:00 UTC
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.
Comment 17 Tom Seewald 2019-01-31 21:47:43 UTC
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.
Comment 18 Dhinakaran Pandiyan 2019-02-01 19:09:16 UTC
(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.
Comment 19 Tom Seewald 2019-02-01 20:48:31 UTC
(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.
Comment 20 Tom Seewald 2019-02-01 20:49:10 UTC
Created attachment 143271 [details]
PSR after boot with fastboot disabled
Comment 21 Tom Seewald 2019-02-01 20:49:26 UTC
Created attachment 143272 [details]
PSR after boot with fastboot enabled
Comment 22 Tom Seewald 2019-02-19 19:56:49 UTC
Friendly update, this is still reproducible on drm-tip as of commit 22cdf0031c984a211ed9edac3979d0156737972d.
Comment 23 Jose Roberto de Souza 2019-02-19 20:49:23 UTC
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.
Comment 24 Jose Roberto de Souza 2019-02-19 20:50:13 UTC
(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?
Comment 25 Tom Seewald 2019-02-19 21:11:13 UTC
(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.
Comment 26 Tom Seewald 2019-03-25 01:29:22 UTC
Now that fastboot is enabled by default on SKL+, is this still be considered a supported configuration? If not, I'll close it.
Comment 27 Jose Roberto de Souza 2019-03-25 23:39:01 UTC
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?
Comment 28 James Ausmus 2019-03-25 23:54:19 UTC
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?
Comment 29 Tom Seewald 2019-03-26 00:14:47 UTC
(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.
Comment 30 Jani Saarinen 2019-11-26 15:53:10 UTC
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.
Comment 31 Tom Seewald 2019-11-26 16:15:32 UTC
(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
Comment 32 Martin Peres 2019-11-29 17:52:03 UTC
-- 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.