[PATCH] drm/i915: Only warn the first time we attempt to mmio whilst suspended

[PATCH] drm/i915: Only warn the first time we attempt to mmio whilst suspended

[Chris Wilson]

In all likelihood we will do a few hundred errnoneous register
operations if we do a single invalid register access whilst the device
is suspended. As each instance causes a WARN, this floods the system
logs and can make the system unresponsive.

The warning was first introduced in
commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65
Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
Date:   Fri Feb 21 13:52:25 2014 -0300

    drm/i915: call assert_device_not_suspended at gen6_force_wake_work

and despite the claims the WARN is still encountered in the wild today.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: stable@vger.kernel.org
---
 drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
index 1a3e485a4f97..f0230b0e8e11 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -43,8 +43,8 @@
 static void
 assert_device_not_suspended(struct drm_i915_private *dev_priv)
 {
-	WARN(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
-	     "Device suspended\n");
+	WARN_ONCE(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
+		  "Device suspended\n");
 }
 
 static void __gen6_gt_wait_for_thread_c0(struct drm_i915_private *dev_priv)
-- 
2.1.3

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Only warn the first time we attempt to mmio whilst suspended

[Daniel Vetter]

On Mon, Nov 24, 2014 at 08:03:12AM +0000, Chris Wilson wrote:
> In all likelihood we will do a few hundred errnoneous register
> operations if we do a single invalid register access whilst the device
> is suspended. As each instance causes a WARN, this floods the system
> logs and can make the system unresponsive.
> 
> The warning was first introduced in
> commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65
> Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Date:   Fri Feb 21 13:52:25 2014 -0300
> 
>     drm/i915: call assert_device_not_suspended at gen6_force_wake_work
> 
> and despite the claims the WARN is still encountered in the wild today.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Cc: stable@vger.kernel.org

I'll pick this up queued for 3.19 (but haven't done the split yet).
-Daniel
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 1a3e485a4f97..f0230b0e8e11 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -43,8 +43,8 @@
>  static void
>  assert_device_not_suspended(struct drm_i915_private *dev_priv)
>  {
> -	WARN(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
> -	     "Device suspended\n");
> +	WARN_ONCE(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
> +		  "Device suspended\n");
>  }
>  
>  static void __gen6_gt_wait_for_thread_c0(struct drm_i915_private *dev_priv)
> -- 
> 2.1.3
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Only warn the first time we attempt

[shuang.he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
PNV                                  367/367              367/367
ILK                 -9              375/375              366/375
SNB                                  450/450              450/450
IVB                 -2              503/503              501/503
BYT                                  289/289              289/289
HSW                 -3              567/567              564/567
BDW                                  417/417              417/417
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
ILK  igt_gem_reset_stats_close-pending-fork-render      TIMEOUT(4, M37M26)PASS(1, M26)      TIMEOUT(1, M26)
ILK  igt_kms_flip_nonexisting-fb      DMESG_WARN(1, M26)PASS(2, M37M26)      DMESG_WARN(1, M26)
ILK  igt_kms_flip_blocking-absolute-wf_vblank-interruptible      DMESG_WARN(2, M26)PASS(1, M37)      DMESG_WARN(1, M26)
ILK  igt_kms_flip_flip-vs-dpms      DMESG_WARN(1, M26)PASS(3, M37M26)      DMESG_WARN(1, M26)
ILK  igt_kms_flip_flip-vs-dpms-interruptible      PASS(3, M37M26)      DMESG_WARN(1, M26)
ILK  igt_kms_flip_flip-vs-panning      DMESG_WARN(1, M26)PASS(1, M37)      DMESG_WARN(1, M26)
ILK  igt_kms_flip_vblank-vs-hang      TIMEOUT(4, M37M26)PASS(1, M26)      TIMEOUT(1, M26)
ILK  igt_kms_flip_wf_vblank-ts-check      PASS(3, M37M26)      DMESG_WARN(1, M26)
ILK  igt_kms_flip_wf_vblank-ts-check-interruptible      DMESG_WARN(1, M26)PASS(3, M37M26)      DMESG_WARN(1, M26)
IVB  igt_gem_bad_reloc_negative-reloc      NSPT(6, M34M21M4)PASS(1, M21)      NSPT(1, M34)
IVB  igt_gem_bad_reloc_negative-reloc-lut      NSPT(3, M21M34M4)PASS(7, M21M34M4)      NSPT(1, M34)
HSW  igt_gem_bad_reloc_negative-reloc-lut      NSPT(15, M40M20M19)PASS(1, M20)      NSPT(1, M19)
HSW  igt_kms_rotation_crc_primary-rotation      PASS(16, M20M40M19)      DMESG_WARN(1, M19)
HSW  igt_pm_rc6_residency_rc6-accuracy      PASS(16, M20M40M19)      FAIL(1, M19)
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Only warn the first time we attempt to mmio whilst suspended

[Paulo Zanoni]

2014-11-24 6:03 GMT-02:00 Chris Wilson <chris@chris-wilson.co.uk>:
> In all likelihood we will do a few hundred errnoneous register
> operations if we do a single invalid register access whilst the device
> is suspended. As each instance causes a WARN, this floods the system
> logs and can make the system unresponsive.
>
> The warning was first introduced in
> commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65
> Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Date:   Fri Feb 21 13:52:25 2014 -0300
>
>     drm/i915: call assert_device_not_suspended at gen6_force_wake_work
>
> and despite the claims the WARN is still encountered in the wild today.

Can you please give us some more information on the WARNs you are
encountering? Any bug numbers? Which platforms? Do we have test cases
for these in IGT? If you can describe the steps to reproduce, we can
try to write some test cases.

I have already debugged bugs related to this WARN, and as far as I
remember, in most cases we only got a few WARN instances, not
"hundreds" of WARNs.

The patch itself is fine, but having a way to trigger all the WARNs -
not just the first one - with i915.mmio_debug would be cool too.

>
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Imre Deak <imre.deak@intel.com>
> Cc: stable@vger.kernel.org
> ---
>  drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
> index 1a3e485a4f97..f0230b0e8e11 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -43,8 +43,8 @@
>  static void
>  assert_device_not_suspended(struct drm_i915_private *dev_priv)
>  {
> -       WARN(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
> -            "Device suspended\n");
> +       WARN_ONCE(HAS_RUNTIME_PM(dev_priv->dev) && dev_priv->pm.suspended,
> +                 "Device suspended\n");
>  }
>
>  static void __gen6_gt_wait_for_thread_c0(struct drm_i915_private *dev_priv)
> --
> 2.1.3
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



-- 
Paulo Zanoni
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Only warn the first time we attempt to mmio whilst suspended

[Chris Wilson]

On Mon, Nov 24, 2014 at 12:11:45PM -0200, Paulo Zanoni wrote:
> 2014-11-24 6:03 GMT-02:00 Chris Wilson <chris@chris-wilson.co.uk>:
> > In all likelihood we will do a few hundred errnoneous register
> > operations if we do a single invalid register access whilst the device
> > is suspended. As each instance causes a WARN, this floods the system
> > logs and can make the system unresponsive.
> >
> > The warning was first introduced in
> > commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65
> > Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > Date:   Fri Feb 21 13:52:25 2014 -0300
> >
> >     drm/i915: call assert_device_not_suspended at gen6_force_wake_work
> >
> > and despite the claims the WARN is still encountered in the wild today.
> 
> Can you please give us some more information on the WARNs you are
> encountering? Any bug numbers? Which platforms? Do we have test cases
> for these in IGT? If you can describe the steps to reproduce, we can
> try to write some test cases.

23:52 < joecool> hey i am having a handful of issues with haswell on
3.17, one of them i keep seeing spammed in dmesg but nowhere else in
logs
00:09 < joecool> i should mention those warnings also appear pretty fast
when my lid is closed sometimes and screen is toggled off (it maxes my
syslog-ng process and often crashes laptop, not just X)

Now that seems to be a critical bug causing data loss. Please fix
immediately.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx