<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Graphical corruption with PSR - affects Plymouth only" href="https://bugs.freedesktop.org/show_bug.cgi?id=107966#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - Graphical corruption with PSR - affects Plymouth only" href="https://bugs.freedesktop.org/show_bug.cgi?id=107966">bug 107966</a> from <a class="email" href="mailto:dhinakaran.pandiyan@intel.com" title="Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>"> Dhinakaran Pandiyan</a> <pre>(In reply to Tom Seewald from <a href="show_bug.cgi?id=107966#c17">comment #17</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are on the CC list for the bug.</li> </ul> </body> </html>