We have also seen screen corruption on this panel when using sequences like

   xset dpms force off
   xset dpms force on

figured I'd mention it in case it was related (using suspend instead of off seems to prevent the corruption).

From the presentation of this bug, I presume this to be a hardware issue manifest in the signalling. When you say a specific panel do you mean one and only panel shows this issue during boot, or is it a class of panels? Is the bug visible only during initialisation or does it persist for the lifetime of the driver and for all modes?

We should verify that the modesetting registers appear sane. Can you please run intel_reg_dumper with and without (or using nomodeset) the i915.ko driver loaded?

Currently it is one specific model of panel that demonstrates the symptom.  The random line is only visible during initialization (although I wonder if the screen corruption during the xset sequences is just a different symptom).

I'll request the data and upload it as soon as I get it.

Created attachment 48655 [details]
intel_reg_dump with driver

Created attachment 48656 [details]
intel_reg_dump without the driver

Sorry for the delay - I've attached the register dumps

There are two important differences between the BIOS and our driver.

1. The BIOS uses a high-power 4x FDI link mode (we use just 1 channel).
2. The BIOS disables non-spread source (which we enable).

We can override the number of lanes to use with:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index e375500..df95b4b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5166,6 +5166,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
                lane = bps / (link_bw * 8) + 1;
        }
 
+       lane = 4;
        intel_crtc->fdi_lanes = lane;
 
        if (pixel_multiplier > 1)

and disable the non-spread source with:

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_d
index e375500..434b78f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5181,7 +5181,7 @@ static int ironlake_crtc_mode_set(struct drm_crtc *crtc,
        temp = I915_READ(PCH_DREF_CONTROL);
        /* Always enable nonspread source */
        temp &= ~DREF_NONSPREAD_SOURCE_MASK;
-       temp |= DREF_NONSPREAD_SOURCE_ENABLE;
+       //temp |= DREF_NONSPREAD_SOURCE_ENABLE;
        temp &= ~DREF_SSC_SOURCE_MASK;
        temp |= DREF_SSC_SOURCE_ENABLE;
        I915_WRITE(PCH_DREF_CONTROL, temp);

Rick, can you please test both of those separately and together on the off-chance they explain the discrepancy?

Thanks Chris - will do.

Dropping priority whilst investigations continue (not going to be fixed by tomorrow!)

Thanks - sorry it's taking so long - I don't have these machines that exhibit the problem and getting someone else to run the test it taking longer than expected.

Hi Guys, unfortunately I've been unsuccessfully at getting these tests run on the system that exhibits the problem.   At this point I'd suggest the bug just get closed with the appropriate state.

I can't think of a reason why we would trick the hardware into behaving outside of its spec, so I'm voting that this is someone else's bug. (Feel free to reopen if we can identify the [root] cause.)