All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] drm/i915: Re-enable GTT following a device reset
@ 2017-09-05 20:47 Chris Wilson
  2017-09-05 21:05 ` ✓ Fi.CI.BAT: success for " Patchwork
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Chris Wilson @ 2017-09-05 20:47 UTC (permalink / raw)
  To: intel-gfx

Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
reset. That was causing the display to show garbage on his 945gm. On my
i915gm the effect was far more severe; re-enabling the display following
the reset without PGETBL_CTL being enabled lead to an immediate hard
hang.

We do have a routine to re-enable PGETBL_CTL which is applicable to
gen2-4, although on gen4 it is documented that a graphics reset doesn't
alter the register (no such wording is given for gen3) and should be safe
to call to punch back in the enable bit. However, that leaves the question
of whether we need to completely re-initialise the register and the
rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
page table, its contents do seem to be kept, and so we should be able to
recover without having to reinitialise the GTT from scratch (as prior to
g33, that register is configured by the BIOS and we leave alone except
for the enable bit).

Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_drv.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f10a078e3a55..3ee107f26ce9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1908,6 +1908,12 @@ void i915_reset(struct drm_i915_private *i915, unsigned int flags)
 		goto error;
 	}
 
+	ret = i915_ggtt_enable_hw(i915);
+	if (ret) {
+		DRM_ERROR("Failed to re-enable GGTT following reset %d\n", ret);
+		goto error;
+	}
+
 	i915_queue_hangcheck(i915);
 
 finish:
-- 
2.14.1

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

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* ✓ Fi.CI.BAT: success for drm/i915: Re-enable GTT following a device reset
  2017-09-05 20:47 [PATCH] drm/i915: Re-enable GTT following a device reset Chris Wilson
@ 2017-09-05 21:05 ` Patchwork
  2017-09-05 23:56 ` ✓ Fi.CI.IGT: " Patchwork
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 9+ messages in thread
From: Patchwork @ 2017-09-05 21:05 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Re-enable GTT following a device reset
URL   : https://patchwork.freedesktop.org/series/29845/
State : success

== Summary ==

Series 29845v1 drm/i915: Re-enable GTT following a device reset
https://patchwork.freedesktop.org/api/1.0/series/29845/revisions/1/mbox/

Test kms_cursor_legacy:
        Subgroup basic-busy-flip-before-cursor-atomic:
                fail       -> PASS       (fi-snb-2600) fdo#100215 +1
Test kms_flip:
        Subgroup basic-flip-vs-modeset:
                pass       -> SKIP       (fi-skl-x1585l) fdo#101781
Test drv_module_reload:
        Subgroup basic-reload-inject:
                dmesg-fail -> DMESG-WARN (fi-cfl-s) k.org#196765

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215
fdo#101781 https://bugs.freedesktop.org/show_bug.cgi?id=101781
k.org#196765 https://bugzilla.kernel.org/show_bug.cgi?id=196765

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:462s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:444s
fi-blb-e6850     total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  time:362s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:560s
fi-bwr-2160      total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 time:254s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:522s
fi-byt-j1900     total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  time:520s
fi-cfl-s         total:289  pass:250  dwarn:4   dfail:0   fail:0   skip:35  time:468s
fi-elk-e7500     total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  time:445s
fi-glk-2a        total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:613s
fi-hsw-4770      total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:445s
fi-hsw-4770r     total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:424s
fi-ilk-650       total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:424s
fi-ivb-3520m     total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:506s
fi-ivb-3770      total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:472s
fi-kbl-7500u     total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  time:516s
fi-kbl-7560u     total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  time:604s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:603s
fi-pnv-d510      total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:527s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:474s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:535s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:517s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:443s
fi-skl-x1585l    total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:483s
fi-snb-2520m     total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  time:554s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:1   skip:39  time:406s
fi-byt-n2820 failed to connect after reboot

22fe7d7fe4c7a6e04c7f7f99d6b8985008616546 drm-tip: 2017y-09m-05d-19h-15m-06s UTC integration manifest
fb35a3bbeb63 drm/i915: Re-enable GTT following a device reset

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5588/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* ✓ Fi.CI.IGT: success for drm/i915: Re-enable GTT following a device reset
  2017-09-05 20:47 [PATCH] drm/i915: Re-enable GTT following a device reset Chris Wilson
  2017-09-05 21:05 ` ✓ Fi.CI.BAT: success for " Patchwork
@ 2017-09-05 23:56 ` Patchwork
  2017-09-06 11:14 ` [PATCH v2] " Chris Wilson
  2017-09-06 11:34 ` ✗ Fi.CI.BAT: warning for drm/i915: Re-enable GTT following a device reset (rev2) Patchwork
  3 siblings, 0 replies; 9+ messages in thread
From: Patchwork @ 2017-09-05 23:56 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Re-enable GTT following a device reset
URL   : https://patchwork.freedesktop.org/series/29845/
State : success

== Summary ==

Test perf:
        Subgroup polling:
                fail       -> PASS       (shard-hsw) fdo#102252
Test kms_fbc_crc:
        Subgroup page_flip_and_render:
                skip       -> PASS       (shard-hsw)
Test kms_busy:
        Subgroup extended-pageflip-modeset-hang-oldfb-render-C:
                skip       -> PASS       (shard-hsw)

fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252

shard-hsw        total:2265 pass:1233 dwarn:0   dfail:0   fail:16  skip:1016 time:9640s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5588/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [PATCH v2] drm/i915: Re-enable GTT following a device reset
  2017-09-05 20:47 [PATCH] drm/i915: Re-enable GTT following a device reset Chris Wilson
  2017-09-05 21:05 ` ✓ Fi.CI.BAT: success for " Patchwork
  2017-09-05 23:56 ` ✓ Fi.CI.IGT: " Patchwork
@ 2017-09-06 11:14 ` Chris Wilson
  2017-09-06 12:13   ` Ville Syrjälä
  2017-09-06 12:23   ` Ville Syrjälä
  2017-09-06 11:34 ` ✗ Fi.CI.BAT: warning for drm/i915: Re-enable GTT following a device reset (rev2) Patchwork
  3 siblings, 2 replies; 9+ messages in thread
From: Chris Wilson @ 2017-09-06 11:14 UTC (permalink / raw)
  To: intel-gfx

Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
reset. That was causing the display to show garbage on his 945gm. On my
i915gm the effect was far more severe; re-enabling the display following
the reset without PGETBL_CTL being enabled lead to an immediate hard
hang.

We do have a routine to re-enable PGETBL_CTL which is applicable to
gen2-4, although on gen4 it is documented that a graphics reset doesn't
alter the register (no such wording is given for gen3) and should be safe
to call to punch back in the enable bit. However, that leaves the question
of whether we need to completely re-initialise the register and the
rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
page table, its contents do seem to be kept, and so we should be able to
recover without having to reinitialise the GTT from scratch (as prior to
g33, that register is configured by the BIOS and we leave alone except
for the enable bit).

This appears to have been broken by commit 5fbd0418eef2 ("drm/i915:
Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
reset) to add it earlier during hw init and resume, missing the reset
path.

v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
match init/resume

Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
---
 drivers/gpu/drm/i915/i915_drv.c | 12 +++++++++---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f10a078e3a55..ff70fc45ba7c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1892,9 +1892,15 @@ void i915_reset(struct drm_i915_private *i915, unsigned int flags)
 
 	/*
 	 * Everything depends on having the GTT running, so we need to start
-	 * there.  Fortunately we don't need to do this unless we reset the
-	 * chip at a PCI level.
-	 *
+	 * there.
+	 */
+	ret = i915_ggtt_enable_hw(i915);
+	if (ret) {
+		DRM_ERROR("Failed to re-enable GGTT following reset %d\n", ret);
+		goto error;
+	}
+
+	/*
 	 * Next we need to restore the context, but we don't use those
 	 * yet either...
 	 *
-- 
2.14.1

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

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* ✗ Fi.CI.BAT: warning for drm/i915: Re-enable GTT following a device reset (rev2)
  2017-09-05 20:47 [PATCH] drm/i915: Re-enable GTT following a device reset Chris Wilson
                   ` (2 preceding siblings ...)
  2017-09-06 11:14 ` [PATCH v2] " Chris Wilson
@ 2017-09-06 11:34 ` Patchwork
  2017-09-06 13:20   ` Chris Wilson
  3 siblings, 1 reply; 9+ messages in thread
From: Patchwork @ 2017-09-06 11:34 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

== Series Details ==

Series: drm/i915: Re-enable GTT following a device reset (rev2)
URL   : https://patchwork.freedesktop.org/series/29845/
State : warning

== Summary ==

Series 29845v2 drm/i915: Re-enable GTT following a device reset
https://patchwork.freedesktop.org/api/1.0/series/29845/revisions/2/mbox/

Test kms_cursor_legacy:
        Subgroup basic-busy-flip-before-cursor-atomic:
                pass       -> FAIL       (fi-snb-2600) fdo#100215 +1
Test pm_rpm:
        Subgroup basic-pci-d3-state:
                pass       -> SKIP       (fi-cfl-s)

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u     total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:454s
fi-bdw-gvtdvm    total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:437s
fi-blb-e6850     total:289  pass:224  dwarn:1   dfail:0   fail:0   skip:64  time:361s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:548s
fi-bwr-2160      total:289  pass:184  dwarn:0   dfail:0   fail:0   skip:105 time:254s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:522s
fi-byt-j1900     total:289  pass:254  dwarn:1   dfail:0   fail:0   skip:34  time:523s
fi-byt-n2820     total:289  pass:250  dwarn:1   dfail:0   fail:0   skip:38  time:514s
fi-cfl-s         total:289  pass:249  dwarn:4   dfail:0   fail:0   skip:36  time:462s
fi-elk-e7500     total:289  pass:230  dwarn:0   dfail:0   fail:0   skip:59  time:440s
fi-glk-2a        total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:615s
fi-hsw-4770      total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:444s
fi-hsw-4770r     total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:424s
fi-ilk-650       total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:424s
fi-ivb-3520m     total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:508s
fi-ivb-3770      total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:475s
fi-kbl-7500u     total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  time:515s
fi-kbl-7560u     total:289  pass:270  dwarn:0   dfail:0   fail:0   skip:19  time:599s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:600s
fi-pnv-d510      total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:524s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:468s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:534s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:520s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:446s
fi-skl-x1585l    total:289  pass:268  dwarn:0   dfail:0   fail:0   skip:21  time:488s
fi-snb-2520m     total:289  pass:251  dwarn:0   dfail:0   fail:0   skip:38  time:555s
fi-snb-2600      total:289  pass:248  dwarn:0   dfail:0   fail:2   skip:39  time:420s

0640ea73be26f37458cfff3943bed7055536da84 drm-tip: 2017y-09m-06d-06h-41m-15s UTC integration manifest
3968667f8b19 drm/i915: Re-enable GTT following a device reset

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_5591/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] drm/i915: Re-enable GTT following a device reset
  2017-09-06 11:14 ` [PATCH v2] " Chris Wilson
@ 2017-09-06 12:13   ` Ville Syrjälä
  2017-09-06 12:44     ` Chris Wilson
  2017-09-06 12:23   ` Ville Syrjälä
  1 sibling, 1 reply; 9+ messages in thread
From: Ville Syrjälä @ 2017-09-06 12:13 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Wed, Sep 06, 2017 at 12:14:05PM +0100, Chris Wilson wrote:
> Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
> reset. That was causing the display to show garbage on his 945gm. On my
> i915gm the effect was far more severe; re-enabling the display following
> the reset without PGETBL_CTL being enabled lead to an immediate hard
> hang.
> 
> We do have a routine to re-enable PGETBL_CTL which is applicable to
> gen2-4, although on gen4 it is documented that a graphics reset doesn't
> alter the register (no such wording is given for gen3) and should be safe
> to call to punch back in the enable bit. However, that leaves the question
> of whether we need to completely re-initialise the register and the
> rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
> page table, its contents do seem to be kept, and so we should be able to
> recover without having to reinitialise the GTT from scratch (as prior to
> g33, that register is configured by the BIOS and we leave alone except
> for the enable bit).
> 
> This appears to have been broken by commit 5fbd0418eef2 ("drm/i915:
> Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
> moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
> reset) to add it earlier during hw init and resume, missing the reset
> path.
> 
> v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
> match init/resume
> 
> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f10a078e3a55..ff70fc45ba7c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1892,9 +1892,15 @@ void i915_reset(struct drm_i915_private *i915, unsigned int flags)
>  
>  	/*
>  	 * Everything depends on having the GTT running, so we need to start
> -	 * there.  Fortunately we don't need to do this unless we reset the
> -	 * chip at a PCI level.
> -	 *
> +	 * there.
> +	 */
> +	ret = i915_ggtt_enable_hw(i915);
> +	if (ret) {
> +		DRM_ERROR("Failed to re-enable GGTT following reset %d\n", ret);
> +		goto error;
> +	}

I do wonder a bit whether the hardware might object to the fact that
we restore fences before the GGTT gets re-enabled. But I suppose it's
possible there's no linkage between the two until someone actually
accesses the GGTT...

CCID/PPGTT also seems to get re-enabled before this but since that's
gen6+ stuff it doesn't matter.

This does help my 945gm, so
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>

> +
> +	/*
>  	 * Next we need to restore the context, but we don't use those
>  	 * yet either...
>  	 *
> -- 
> 2.14.1

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] drm/i915: Re-enable GTT following a device reset
  2017-09-06 11:14 ` [PATCH v2] " Chris Wilson
  2017-09-06 12:13   ` Ville Syrjälä
@ 2017-09-06 12:23   ` Ville Syrjälä
  1 sibling, 0 replies; 9+ messages in thread
From: Ville Syrjälä @ 2017-09-06 12:23 UTC (permalink / raw)
  To: Chris Wilson; +Cc: intel-gfx

On Wed, Sep 06, 2017 at 12:14:05PM +0100, Chris Wilson wrote:
> Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
> reset. That was causing the display to show garbage on his 945gm. On my
> i915gm the effect was far more severe; re-enabling the display following
> the reset without PGETBL_CTL being enabled lead to an immediate hard
> hang.
> 
> We do have a routine to re-enable PGETBL_CTL which is applicable to
> gen2-4, although on gen4 it is documented that a graphics reset doesn't
> alter the register (no such wording is given for gen3) and should be safe
> to call to punch back in the enable bit. However, that leaves the question
> of whether we need to completely re-initialise the register and the
> rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
> page table, its contents do seem to be kept, and so we should be able to
> recover without having to reinitialise the GTT from scratch (as prior to
> g33, that register is configured by the BIOS and we leave alone except
> for the enable bit).
> 
> This appears to have been broken by commit 5fbd0418eef2 ("drm/i915:
> Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
> moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
> reset) to add it earlier during hw init and resume, missing the reset
> path.
> 
> v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
> match init/resume
> 
> Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms")

Ouch. So it was me that broke this. Sorry about that folks.

> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
> ---
>  drivers/gpu/drm/i915/i915_drv.c | 12 +++++++++---
>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f10a078e3a55..ff70fc45ba7c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1892,9 +1892,15 @@ void i915_reset(struct drm_i915_private *i915, unsigned int flags)
>  
>  	/*
>  	 * Everything depends on having the GTT running, so we need to start
> -	 * there.  Fortunately we don't need to do this unless we reset the
> -	 * chip at a PCI level.
> -	 *
> +	 * there.
> +	 */
> +	ret = i915_ggtt_enable_hw(i915);
> +	if (ret) {
> +		DRM_ERROR("Failed to re-enable GGTT following reset %d\n", ret);
> +		goto error;
> +	}
> +
> +	/*
>  	 * Next we need to restore the context, but we don't use those
>  	 * yet either...
>  	 *
> -- 
> 2.14.1

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH v2] drm/i915: Re-enable GTT following a device reset
  2017-09-06 12:13   ` Ville Syrjälä
@ 2017-09-06 12:44     ` Chris Wilson
  0 siblings, 0 replies; 9+ messages in thread
From: Chris Wilson @ 2017-09-06 12:44 UTC (permalink / raw)
  To: Ville Syrjälä; +Cc: intel-gfx

Quoting Ville Syrjälä (2017-09-06 13:13:05)
> On Wed, Sep 06, 2017 at 12:14:05PM +0100, Chris Wilson wrote:
> > Ville Syrjälä spotted that PGETBL_CTL was losing its enable bit upon a
> > reset. That was causing the display to show garbage on his 945gm. On my
> > i915gm the effect was far more severe; re-enabling the display following
> > the reset without PGETBL_CTL being enabled lead to an immediate hard
> > hang.
> > 
> > We do have a routine to re-enable PGETBL_CTL which is applicable to
> > gen2-4, although on gen4 it is documented that a graphics reset doesn't
> > alter the register (no such wording is given for gen3) and should be safe
> > to call to punch back in the enable bit. However, that leaves the question
> > of whether we need to completely re-initialise the register and the
> > rest of the GSM. For g33/pnv/gen4+, where we do have a configurable
> > page table, its contents do seem to be kept, and so we should be able to
> > recover without having to reinitialise the GTT from scratch (as prior to
> > g33, that register is configured by the BIOS and we leave alone except
> > for the enable bit).
> > 
> > This appears to have been broken by commit 5fbd0418eef2 ("drm/i915:
> > Re-enable GGTT earlier during resume on pre-gen6 platforms"), which
> > moved the intel_enable_gtt() from i915_gem_init_hw() (also used by
> > reset) to add it earlier during hw init and resume, missing the reset
> > path.
> > 
> > v2: Find the culprit, rearrange ggtt_enable to be before gem_init_hw to
> > match init/resume
> > 
> > Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Fixes: 5fbd0418eef2 ("drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101852
> > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > Cc: Daniel Vetter <daniel@ffwll.ch>
> > Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c | 12 +++++++++---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> > index f10a078e3a55..ff70fc45ba7c 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1892,9 +1892,15 @@ void i915_reset(struct drm_i915_private *i915, unsigned int flags)
> >  
> >       /*
> >        * Everything depends on having the GTT running, so we need to start
> > -      * there.  Fortunately we don't need to do this unless we reset the
> > -      * chip at a PCI level.
> > -      *
> > +      * there.
> > +      */
> > +     ret = i915_ggtt_enable_hw(i915);
> > +     if (ret) {
> > +             DRM_ERROR("Failed to re-enable GGTT following reset %d\n", ret);
> > +             goto error;
> > +     }
> 
> I do wonder a bit whether the hardware might object to the fact that
> we restore fences before the GGTT gets re-enabled. But I suppose it's
> possible there's no linkage between the two until someone actually
> accesses the GGTT...

That's a reasonable suggestion. The real challenge is finding a name for
each step ;)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: ✗ Fi.CI.BAT: warning for drm/i915: Re-enable GTT following a device reset (rev2)
  2017-09-06 11:34 ` ✗ Fi.CI.BAT: warning for drm/i915: Re-enable GTT following a device reset (rev2) Patchwork
@ 2017-09-06 13:20   ` Chris Wilson
  0 siblings, 0 replies; 9+ messages in thread
From: Chris Wilson @ 2017-09-06 13:20 UTC (permalink / raw)
  To: Patchwork; +Cc: intel-gfx

Quoting Patchwork (2017-09-06 12:34:12)
> == Series Details ==
> 
> Series: drm/i915: Re-enable GTT following a device reset (rev2)
> URL   : https://patchwork.freedesktop.org/series/29845/
> State : warning
> 
> == Summary ==
> 
> Series 29845v2 drm/i915: Re-enable GTT following a device reset
> https://patchwork.freedesktop.org/api/1.0/series/29845/revisions/2/mbox/
> 
> Test kms_cursor_legacy:
>         Subgroup basic-busy-flip-before-cursor-atomic:
>                 pass       -> FAIL       (fi-snb-2600) fdo#100215 +1
> Test pm_rpm:
>         Subgroup basic-pci-d3-state:
>                 pass       -> SKIP       (fi-cfl-s)
> 
> fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

Double checked that the reordering still fixes my i915gm; with CI
checking that we haven't broken hang recovery elsewhere.

Pushed, many thanks that after many deadends, on the world's slowest
netbook, we have this resolved.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2017-09-06 13:20 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-09-05 20:47 [PATCH] drm/i915: Re-enable GTT following a device reset Chris Wilson
2017-09-05 21:05 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-09-05 23:56 ` ✓ Fi.CI.IGT: " Patchwork
2017-09-06 11:14 ` [PATCH v2] " Chris Wilson
2017-09-06 12:13   ` Ville Syrjälä
2017-09-06 12:44     ` Chris Wilson
2017-09-06 12:23   ` Ville Syrjälä
2017-09-06 11:34 ` ✗ Fi.CI.BAT: warning for drm/i915: Re-enable GTT following a device reset (rev2) Patchwork
2017-09-06 13:20   ` Chris Wilson

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.