Skip to content

Delay in skl_disable_plane() causes a system freeze

Submitted by Azhar

Assigned to Ville Syrjälä @vsyrjala

Link to original bug (#104975)

Description

Created attachment 137193
Drm logs with 0x1e log level

When a 50ms delay happens on KBL-Y and KBL-U between these two register writes, the system hard hangs with a corrupted display (see attachments). 100ms reproduces even more frequently.

diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 4a8a5d918a83..b94eddb04d24 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -311,30 +311,31 @@ void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state)
spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
}

void
skl_disable_plane(struct intel_plane *plane, struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
enum plane_id plane_id = plane->id;
enum pipe pipe = plane->pipe;
unsigned long irqflags;

spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);

I915_WRITE_FW(PLANE_CTL(pipe, plane_id), 0);

  •   mdelay(50);<br>
  I915_WRITE_FW(PLANE_SURF(pipe, plane_id), 0);<br>
  POSTING_READ_FW(PLANE_SURF(pipe, plane_id));<br>

spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
}


This has been reproduced on a variety of KBL-Y and KBL-U SKUs, and with both coreboot firmware and UEFI version KBLSE2R1. R00. X094. P02. 1706220744 on a KBL-Y RVP.

This was reproduced with chromeos-4.14 https://chromium.googlesource.com/chromiumos/third_party/kernel/+/9325afcd11534271/drivers/gpu/drm/i915/ and linux stable 4.15.1 tag

This is reproduced with maxcpus=1.
Hardware video decoder is required to reproduce the issue.
Sysrq does not work after system freeze. ITP halt() fails to stop the CPUS.

The first reports came from a ChromeOS autotest which does the following:
1. Login as a test account
2. Play a vp9 or vp8 video for 10secs
3. restart ui (roughly equivalent to “service mydisplaymanager restart”)

Of course this test was initially not run with a mdelay() added in the kernel - which is why reproduction was extremely rare. It took weeks to narrow down the issue to that specific delay.

To reproduce the issue manually (without running autotest) execute the below steps
1) Play any video in 1080p from crosvideo.appspot.com
2) Monitor the i915_display_info to make sure the overlay plane is active.
3) Once overlay plane is active move the cursor on top of the overlay plane. This disables the overlay plane.
4) When the overlay plane is disabled the system freezes.

**Attachment 137193**, "Drm logs with 0x1e log level":
drm-logs-on-4.15.1-linux-stable.log
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information