* [PATCH 1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
@ 2020-10-07 12:03 ` Ville Syrjala
0 siblings, 0 replies; 13+ messages in thread
From: Ville Syrjala @ 2020-10-07 12:03 UTC (permalink / raw)
To: intel-gfx; +Cc: stable, Chris Wilson
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Currently we leave the cache_level of the initial fb obj
set to NONE. This means on eLLC machines the first pin_to_display()
will try to switch it to WT which requires a vma unbind+bind.
If that happens during the fbdev initialization rcu does not
seem operational which causes the unbind to get stuck. To
most appearances this looks like a dead machine on boot.
Avoid the unbind by already marking the object cache_level
as WT when creating it. We still do an excplicit ggtt pin
which will rewrite the PTEs anyway, so they will match whatever
cache level we set.
Cc: <stable@vger.kernel.org> # v5.7+
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 907e1d155443..00c08600c60a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3445,6 +3445,14 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(obj))
return NULL;
+ /*
+ * Mark it WT ahead of time to avoid changing the
+ * cache_level during fbdev initialization. The
+ * unbind there would get stuck waiting for rcu.
+ */
+ i915_gem_object_set_cache_coherency(obj, HAS_WT(i915) ?
+ I915_CACHE_WT : I915_CACHE_NONE);
+
switch (plane_config->tiling) {
case I915_TILING_NONE:
break;
--
2.26.2
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Intel-gfx] [PATCH 1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
@ 2020-10-07 12:03 ` Ville Syrjala
0 siblings, 0 replies; 13+ messages in thread
From: Ville Syrjala @ 2020-10-07 12:03 UTC (permalink / raw)
To: intel-gfx; +Cc: stable, Chris Wilson
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Currently we leave the cache_level of the initial fb obj
set to NONE. This means on eLLC machines the first pin_to_display()
will try to switch it to WT which requires a vma unbind+bind.
If that happens during the fbdev initialization rcu does not
seem operational which causes the unbind to get stuck. To
most appearances this looks like a dead machine on boot.
Avoid the unbind by already marking the object cache_level
as WT when creating it. We still do an excplicit ggtt pin
which will rewrite the PTEs anyway, so they will match whatever
cache level we set.
Cc: <stable@vger.kernel.org> # v5.7+
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index 907e1d155443..00c08600c60a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3445,6 +3445,14 @@ initial_plane_vma(struct drm_i915_private *i915,
if (IS_ERR(obj))
return NULL;
+ /*
+ * Mark it WT ahead of time to avoid changing the
+ * cache_level during fbdev initialization. The
+ * unbind there would get stuck waiting for rcu.
+ */
+ i915_gem_object_set_cache_coherency(obj, HAS_WT(i915) ?
+ I915_CACHE_WT : I915_CACHE_NONE);
+
switch (plane_config->tiling) {
case I915_TILING_NONE:
break;
--
2.26.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Intel-gfx] [PATCH 2/3] drm/i915: Fix MOCS PTE setting for gen9+
2020-10-07 12:03 ` [Intel-gfx] " Ville Syrjala
(?)
@ 2020-10-07 12:03 ` Ville Syrjala
2020-10-13 15:51 ` Chris Wilson
-1 siblings, 1 reply; 13+ messages in thread
From: Ville Syrjala @ 2020-10-07 12:03 UTC (permalink / raw)
To: intel-gfx
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fix up the MOCS PTE setting to really get the LLC cacheability
from the PTE rather than hardocoding it to LLC or LLC+eLLC.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 632e08a4592b..6f771a482608 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -124,7 +124,7 @@ struct drm_i915_mocs_table {
LE_1_UC | LE_TC_2_LLC_ELLC, \
L3_1_UC), \
MOCS_ENTRY(I915_MOCS_PTE, \
- LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3), \
+ LE_0_PAGETABLE | LE_TC_0_PAGETABLE | LE_LRUM(3), \
L3_3_WB)
static const struct drm_i915_mocs_entry skl_mocs_table[] = {
@@ -274,7 +274,7 @@ static const struct drm_i915_mocs_entry icl_mocs_table[] = {
L3_1_UC),
/* Base - L3 + LeCC:PAT (Deprecated) */
MOCS_ENTRY(I915_MOCS_PTE,
- LE_0_PAGETABLE | LE_TC_1_LLC,
+ LE_0_PAGETABLE | LE_TC_0_PAGETABLE,
L3_3_WB),
GEN11_MOCS_ENTRIES
--
2.26.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Intel-gfx] [PATCH 3/3] drm/i915: Enable eLLC caching of display buffers for SKL+
2020-10-07 12:03 ` [Intel-gfx] " Ville Syrjala
(?)
(?)
@ 2020-10-07 12:03 ` Ville Syrjala
-1 siblings, 0 replies; 13+ messages in thread
From: Ville Syrjala @ 2020-10-07 12:03 UTC (permalink / raw)
To: intel-gfx; +Cc: Eero Tamminen, Chris Wilson
From: Ville Syrjälä <ville.syrjala@linux.intel.com>
Since SKL the eLLC has been sitting on the far side of the system
agent, meaning the display engine can utilize it. Let's enable that.
I chose WB for the caching mode, because my numbers are indicating
that WT might actually be WB and WC might actually be UC. I'm not
100% sure that is indeed the case but at least my simple rendercopy
based benchmark didn't see any difference in performance.
Also if I configure things to do LLCeLLC+WT I still get cache dirt
on my screen, suggesting that is in fact operating in WB mode
anyway. This is also the reason I had to fix the MOCS target cache
to really say PTE rather than LLC+eLLC.
Since SKL the eLLC has been sitting on the far side of the system agent,
meaning the display engine can utilize it. Let's enable that.
Eero's earlier benchmarks numbers:
"* Results in GfxBench and Unigine (Valley/Heaven) tests were within daily
variation on the tested SKL machines
* SKL GT4e (128MB eLLC) / Wayland / Weston:
+15-20% SynMark TexMem512 (512MB of textures)
+4-6% SynMark TerrainFly*, CSCloth, ShMapVsm
-5-10% SynMark TexMem128 (128MB of textures)
* SKL GT3e (64MB eLLC) / Xorg / Unity:
+4-8% GpuTest Triangle fullscreen (FullHD)
-5-10% GpuTest Triangle windowed (1/2 screen)
* SKL GT2 (no eLLC) / Xorg / Unity:
* Some of the higher FPS SynMark pixel and vertex shader tests
are few percent higher, more than daily variance
=> Do you see any reason why this machine would be impacted
although it doesn't eLLC?"
Caveats:
- Still haven't tested with a prime setup
- Still not entirely sure this a good idea, but I've been
using it on my cfl anyway :)
v2: Split the MOCS PTE change out
Cc: Eero Tamminen <eero.t.tamminen@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 10 ++++++++--
drivers/gpu/drm/i915/i915_drv.h | 3 +--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.c b/drivers/gpu/drm/i915/gt/intel_gtt.c
index 3f1114b58b01..7bfe9072be9a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.c
@@ -324,7 +324,7 @@ static void cnl_setup_private_ppat(struct intel_uncore *uncore)
GEN8_PPAT_WC | GEN8_PPAT_LLCELLC);
intel_uncore_write(uncore,
GEN10_PAT_INDEX(2),
- GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
+ GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
intel_uncore_write(uncore,
GEN10_PAT_INDEX(3),
GEN8_PPAT_UC);
@@ -349,17 +349,23 @@ static void cnl_setup_private_ppat(struct intel_uncore *uncore)
*/
static void bdw_setup_private_ppat(struct intel_uncore *uncore)
{
+ struct drm_i915_private *i915 = uncore->i915;
u64 pat;
pat = GEN8_PPAT(0, GEN8_PPAT_WB | GEN8_PPAT_LLC) | /* for normal objects, no eLLC */
GEN8_PPAT(1, GEN8_PPAT_WC | GEN8_PPAT_LLCELLC) | /* for something pointing to ptes? */
- GEN8_PPAT(2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC) | /* for scanout with eLLC */
GEN8_PPAT(3, GEN8_PPAT_UC) | /* Uncached objects, mostly for scanout */
GEN8_PPAT(4, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(0)) |
GEN8_PPAT(5, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(1)) |
GEN8_PPAT(6, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(2)) |
GEN8_PPAT(7, GEN8_PPAT_WB | GEN8_PPAT_LLCELLC | GEN8_PPAT_AGE(3));
+ /* for scanout with eLLC */
+ if (INTEL_GEN(i915) >= 9)
+ pat |= GEN8_PPAT(2, GEN8_PPAT_WB | GEN8_PPAT_ELLC_OVERRIDE);
+ else
+ pat |= GEN8_PPAT(2, GEN8_PPAT_WT | GEN8_PPAT_LLCELLC);
+
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_LO, lower_32_bits(pat));
intel_uncore_write(uncore, GEN8_PRIVATE_PAT_HI, upper_32_bits(pat));
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index eef9a821c49c..76cf014eaa6b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1638,8 +1638,7 @@ tgl_revids_get(struct drm_i915_private *dev_priv)
#define HAS_SNOOP(dev_priv) (INTEL_INFO(dev_priv)->has_snoop)
#define HAS_EDRAM(dev_priv) ((dev_priv)->edram_size_mb)
#define HAS_SECURE_BATCHES(dev_priv) (INTEL_GEN(dev_priv) < 6)
-#define HAS_WT(dev_priv) ((IS_HASWELL(dev_priv) || \
- IS_BROADWELL(dev_priv)) && HAS_EDRAM(dev_priv))
+#define HAS_WT(dev_priv) HAS_EDRAM(dev_priv)
#define HWS_NEEDS_PHYSICAL(dev_priv) (INTEL_INFO(dev_priv)->hws_needs_physical)
--
2.26.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 13+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
2020-10-07 12:03 ` [Intel-gfx] " Ville Syrjala
` (2 preceding siblings ...)
(?)
@ 2020-10-07 13:37 ` Patchwork
-1 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2020-10-07 13:37 UTC (permalink / raw)
To: Ville Syrjala; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 5895 bytes --]
== Series Details ==
Series: series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
URL : https://patchwork.freedesktop.org/series/82438/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9109 -> Patchwork_18646
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/index.html
Known issues
------------
Here are the changes found in Patchwork_18646 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][1] -> [DMESG-WARN][2] ([i915#62] / [i915#92] / [i915#95])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_busy@basic@flip.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-kbl-x1275/igt@kms_busy@basic@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +1 similar issue
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-atomic.html
* igt@vgem_basic@unload:
- fi-skl-guc: [PASS][5] -> [DMESG-WARN][6] ([i915#2203])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-skl-guc/igt@vgem_basic@unload.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-skl-guc/igt@vgem_basic@unload.html
#### Possible fixes ####
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8]
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-byt-j1900/igt@i915_pm_rpm@basic-pci-d3-state.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-byt-j1900/igt@i915_pm_rpm@basic-pci-d3-state.html
* igt@i915_pm_rpm@module-reload:
- fi-apl-guc: [DMESG-WARN][9] ([i915#1635] / [i915#1982]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-apl-guc/igt@i915_pm_rpm@module-reload.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-apl-guc/igt@i915_pm_rpm@module-reload.html
* igt@kms_busy@basic@flip:
- {fi-tgl-dsi}: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-tgl-dsi/igt@kms_busy@basic@flip.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-tgl-dsi/igt@kms_busy@basic@flip.html
* igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1:
- fi-icl-u2: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14] +1 similar issue
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vblank@c-edp1.html
#### Warnings ####
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][15] ([i915#62]) -> [DMESG-FAIL][16] ([i915#62] / [i915#95])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-kbl-x1275/igt@i915_pm_rpm@module-reload.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95]) -> [DMESG-WARN][18] ([i915#62] / [i915#92]) +4 similar issues
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-kbl-x1275/igt@kms_cursor_legacy@basic-flip-before-cursor-varying-size.html
* igt@kms_force_connector_basic@prune-stale-modes:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92]) -> [DMESG-WARN][20] ([i915#62] / [i915#92] / [i915#95]) +3 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9109/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/fi-kbl-x1275/igt@kms_force_connector_basic@prune-stale-modes.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (45 -> 39)
------------------------------
Missing (6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_9109 -> Patchwork_18646
CI-20190529: 20190529
CI_DRM_9109: 96e1886f0244ba6e235730b1da9146e71ed6ff3c @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5803: 33f07391e5f6a8d9323e471c81db3f29f91ed4d7 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18646: f89ac6db5b2b380dc84fd92db8f4a5e487549535 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f89ac6db5b2b drm/i915: Enable eLLC caching of display buffers for SKL+
6b1077eb48e9 drm/i915: Fix MOCS PTE setting for gen9+
d8a68a242a82 drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18646/index.html
[-- Attachment #1.2: Type: text/html, Size: 7866 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
2020-10-07 12:03 ` [Intel-gfx] " Ville Syrjala
@ 2020-10-13 15:47 ` Chris Wilson
-1 siblings, 0 replies; 13+ messages in thread
From: Chris Wilson @ 2020-10-13 15:47 UTC (permalink / raw)
To: Ville Syrjala, intel-gfx; +Cc: stable
See subject, s/ininitial/iniital/
Quoting Ville Syrjala (2020-10-07 13:03:27)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Currently we leave the cache_level of the initial fb obj
> set to NONE. This means on eLLC machines the first pin_to_display()
> will try to switch it to WT which requires a vma unbind+bind.
> If that happens during the fbdev initialization rcu does not
> seem operational which causes the unbind to get stuck. To
> most appearances this looks like a dead machine on boot.
>
> Avoid the unbind by already marking the object cache_level
> as WT when creating it. We still do an excplicit ggtt pin
> which will rewrite the PTEs anyway, so they will match whatever
> cache level we set.
>
> Cc: <stable@vger.kernel.org> # v5.7+
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 907e1d155443..00c08600c60a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3445,6 +3445,14 @@ initial_plane_vma(struct drm_i915_private *i915,
> if (IS_ERR(obj))
> return NULL;
>
> + /*
> + * Mark it WT ahead of time to avoid changing the
> + * cache_level during fbdev initialization. The
> + * unbind there would get stuck waiting for rcu.
> + */
> + i915_gem_object_set_cache_coherency(obj, HAS_WT(i915) ?
> + I915_CACHE_WT : I915_CACHE_NONE);
Ok, I've been worrying about whether there were any more side-effects,
but I think it all comes out in the wash. The proof is definitely in the
eating, and we will know soon enough if we break someone's virtual
terminal.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
@ 2020-10-13 15:47 ` Chris Wilson
0 siblings, 0 replies; 13+ messages in thread
From: Chris Wilson @ 2020-10-13 15:47 UTC (permalink / raw)
To: Ville Syrjala, intel-gfx; +Cc: stable
See subject, s/ininitial/iniital/
Quoting Ville Syrjala (2020-10-07 13:03:27)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Currently we leave the cache_level of the initial fb obj
> set to NONE. This means on eLLC machines the first pin_to_display()
> will try to switch it to WT which requires a vma unbind+bind.
> If that happens during the fbdev initialization rcu does not
> seem operational which causes the unbind to get stuck. To
> most appearances this looks like a dead machine on boot.
>
> Avoid the unbind by already marking the object cache_level
> as WT when creating it. We still do an excplicit ggtt pin
> which will rewrite the PTEs anyway, so they will match whatever
> cache level we set.
>
> Cc: <stable@vger.kernel.org> # v5.7+
> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> index 907e1d155443..00c08600c60a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3445,6 +3445,14 @@ initial_plane_vma(struct drm_i915_private *i915,
> if (IS_ERR(obj))
> return NULL;
>
> + /*
> + * Mark it WT ahead of time to avoid changing the
> + * cache_level during fbdev initialization. The
> + * unbind there would get stuck waiting for rcu.
> + */
> + i915_gem_object_set_cache_coherency(obj, HAS_WT(i915) ?
> + I915_CACHE_WT : I915_CACHE_NONE);
Ok, I've been worrying about whether there were any more side-effects,
but I think it all comes out in the wash. The proof is definitely in the
eating, and we will know soon enough if we break someone's virtual
terminal.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix MOCS PTE setting for gen9+
2020-10-07 12:03 ` [Intel-gfx] [PATCH 2/3] drm/i915: Fix MOCS PTE setting for gen9+ Ville Syrjala
@ 2020-10-13 15:51 ` Chris Wilson
2020-10-13 16:11 ` Ville Syrjälä
0 siblings, 1 reply; 13+ messages in thread
From: Chris Wilson @ 2020-10-13 15:51 UTC (permalink / raw)
To: Ville Syrjala, intel-gfx
Quoting Ville Syrjala (2020-10-07 13:03:28)
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> Fix up the MOCS PTE setting to really get the LLC cacheability
> from the PTE rather than hardocoding it to LLC or LLC+eLLC.
>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c b/drivers/gpu/drm/i915/gt/intel_mocs.c
> index 632e08a4592b..6f771a482608 100644
> --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> @@ -124,7 +124,7 @@ struct drm_i915_mocs_table {
> LE_1_UC | LE_TC_2_LLC_ELLC, \
> L3_1_UC), \
> MOCS_ENTRY(I915_MOCS_PTE, \
> - LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3), \
> + LE_0_PAGETABLE | LE_TC_0_PAGETABLE | LE_LRUM(3), \
> L3_3_WB)
>
> static const struct drm_i915_mocs_entry skl_mocs_table[] = {
> @@ -274,7 +274,7 @@ static const struct drm_i915_mocs_entry icl_mocs_table[] = {
> L3_1_UC),
> /* Base - L3 + LeCC:PAT (Deprecated) */
> MOCS_ENTRY(I915_MOCS_PTE,
> - LE_0_PAGETABLE | LE_TC_1_LLC,
> + LE_0_PAGETABLE | LE_TC_0_PAGETABLE,
> L3_3_WB),
Makes sense. Did the PAGETABLE bit carry forward into tgl? That might
fixup the new regression...
For the two given here, it certainly exists and makes a whole lot of
sense,
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix MOCS PTE setting for gen9+
2020-10-13 15:51 ` Chris Wilson
@ 2020-10-13 16:11 ` Ville Syrjälä
0 siblings, 0 replies; 13+ messages in thread
From: Ville Syrjälä @ 2020-10-13 16:11 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
On Tue, Oct 13, 2020 at 04:51:00PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2020-10-07 13:03:28)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Fix up the MOCS PTE setting to really get the LLC cacheability
> > from the PTE rather than hardocoding it to LLC or LLC+eLLC.
> >
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/gt/intel_mocs.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > index 632e08a4592b..6f771a482608 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_mocs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
> > @@ -124,7 +124,7 @@ struct drm_i915_mocs_table {
> > LE_1_UC | LE_TC_2_LLC_ELLC, \
> > L3_1_UC), \
> > MOCS_ENTRY(I915_MOCS_PTE, \
> > - LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3), \
> > + LE_0_PAGETABLE | LE_TC_0_PAGETABLE | LE_LRUM(3), \
> > L3_3_WB)
> >
> > static const struct drm_i915_mocs_entry skl_mocs_table[] = {
> > @@ -274,7 +274,7 @@ static const struct drm_i915_mocs_entry icl_mocs_table[] = {
> > L3_1_UC),
> > /* Base - L3 + LeCC:PAT (Deprecated) */
> > MOCS_ENTRY(I915_MOCS_PTE,
> > - LE_0_PAGETABLE | LE_TC_1_LLC,
> > + LE_0_PAGETABLE | LE_TC_0_PAGETABLE,
> > L3_3_WB),
>
> Makes sense. Did the PAGETABLE bit carry forward into tgl? That might
> fixup the new regression...
At least I still see it in the docs. What troubles me here is the
"deprecated" comment someone added. If this is deprecated how are we
supposed to configure cachine for display surfaces?
>
> For the two given here, it certainly exists and makes a whole lot of
> sense,
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
2020-10-13 15:47 ` [Intel-gfx] " Chris Wilson
@ 2020-10-13 16:12 ` Ville Syrjälä
-1 siblings, 0 replies; 13+ messages in thread
From: Ville Syrjälä @ 2020-10-13 16:12 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, stable
On Tue, Oct 13, 2020 at 04:47:49PM +0100, Chris Wilson wrote:
> See subject, s/ininitial/iniital/
>
> Quoting Ville Syrjala (2020-10-07 13:03:27)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Currently we leave the cache_level of the initial fb obj
> > set to NONE. This means on eLLC machines the first pin_to_display()
> > will try to switch it to WT which requires a vma unbind+bind.
> > If that happens during the fbdev initialization rcu does not
> > seem operational which causes the unbind to get stuck. To
> > most appearances this looks like a dead machine on boot.
> >
> > Avoid the unbind by already marking the object cache_level
> > as WT when creating it. We still do an excplicit ggtt pin
> > which will rewrite the PTEs anyway, so they will match whatever
> > cache level we set.
> >
> > Cc: <stable@vger.kernel.org> # v5.7+
> > Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> > index 907e1d155443..00c08600c60a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -3445,6 +3445,14 @@ initial_plane_vma(struct drm_i915_private *i915,
> > if (IS_ERR(obj))
> > return NULL;
> >
> > + /*
> > + * Mark it WT ahead of time to avoid changing the
> > + * cache_level during fbdev initialization. The
> > + * unbind there would get stuck waiting for rcu.
> > + */
> > + i915_gem_object_set_cache_coherency(obj, HAS_WT(i915) ?
> > + I915_CACHE_WT : I915_CACHE_NONE);
>
> Ok, I've been worrying about whether there were any more side-effects,
> but I think it all comes out in the wash. The proof is definitely in the
> eating, and we will know soon enough if we break someone's virtual
> terminal.
At least it seems to work on my CFL with eLLC caching enabled.
>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Ta.
--
Ville Syrjälä
Intel
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [Intel-gfx] [PATCH 1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
@ 2020-10-13 16:12 ` Ville Syrjälä
0 siblings, 0 replies; 13+ messages in thread
From: Ville Syrjälä @ 2020-10-13 16:12 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx, stable
On Tue, Oct 13, 2020 at 04:47:49PM +0100, Chris Wilson wrote:
> See subject, s/ininitial/iniital/
>
> Quoting Ville Syrjala (2020-10-07 13:03:27)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> >
> > Currently we leave the cache_level of the initial fb obj
> > set to NONE. This means on eLLC machines the first pin_to_display()
> > will try to switch it to WT which requires a vma unbind+bind.
> > If that happens during the fbdev initialization rcu does not
> > seem operational which causes the unbind to get stuck. To
> > most appearances this looks like a dead machine on boot.
> >
> > Avoid the unbind by already marking the object cache_level
> > as WT when creating it. We still do an excplicit ggtt pin
> > which will rewrite the PTEs anyway, so they will match whatever
> > cache level we set.
> >
> > Cc: <stable@vger.kernel.org> # v5.7+
> > Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2381
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
> > index 907e1d155443..00c08600c60a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -3445,6 +3445,14 @@ initial_plane_vma(struct drm_i915_private *i915,
> > if (IS_ERR(obj))
> > return NULL;
> >
> > + /*
> > + * Mark it WT ahead of time to avoid changing the
> > + * cache_level during fbdev initialization. The
> > + * unbind there would get stuck waiting for rcu.
> > + */
> > + i915_gem_object_set_cache_coherency(obj, HAS_WT(i915) ?
> > + I915_CACHE_WT : I915_CACHE_NONE);
>
> Ok, I've been worrying about whether there were any more side-effects,
> but I think it all comes out in the wash. The proof is definitely in the
> eating, and we will know soon enough if we break someone's virtual
> terminal.
At least it seems to work on my CFL with eLLC caching enabled.
>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Ta.
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init (rev2)
2020-10-07 12:03 ` [Intel-gfx] " Ville Syrjala
` (4 preceding siblings ...)
(?)
@ 2020-10-13 19:15 ` Patchwork
-1 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2020-10-13 19:15 UTC (permalink / raw)
To: Ville Syrjala; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 6432 bytes --]
== Series Details ==
Series: series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init (rev2)
URL : https://patchwork.freedesktop.org/series/82438/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9136 -> Patchwork_18691
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/index.html
Known issues
------------
Here are the changes found in Patchwork_18691 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_flink_basic@double-flink:
- fi-tgl-y: [PASS][1] -> [DMESG-WARN][2] ([i915#402]) +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-tgl-y/igt@gem_flink_basic@double-flink.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-tgl-y/igt@gem_flink_basic@double-flink.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1:
- fi-icl-u2: [PASS][5] -> [DMESG-WARN][6] ([i915#1982]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-icl-u2/igt@kms_flip@basic-flip-vs-wf_vblank@b-edp1.html
#### Possible fixes ####
* igt@gem_flink_basic@flink-lifetime:
- fi-tgl-y: [DMESG-WARN][7] ([i915#402]) -> [PASS][8] +1 similar issue
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-tgl-y/igt@gem_flink_basic@flink-lifetime.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-tgl-y/igt@gem_flink_basic@flink-lifetime.html
* igt@i915_module_load@reload:
- {fi-tgl-dsi}: [DMESG-WARN][9] ([i915#1982] / [k.org#205379]) -> [PASS][10]
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-tgl-dsi/igt@i915_module_load@reload.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-tgl-dsi/igt@i915_module_load@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-n3050: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-bsw-n3050/igt@i915_pm_rpm@basic-pci-d3-state.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-bsw-n3050/igt@i915_pm_rpm@basic-pci-d3-state.html
* igt@kms_busy@basic@flip:
- {fi-kbl-7560u}: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-kbl-7560u/igt@kms_busy@basic@flip.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-kbl-7560u/igt@kms_busy@basic@flip.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-kefka: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16]
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-icl-u2/igt@kms_cursor_legacy@basic-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-tgl-y: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-tgl-y/igt@kms_pipe_crc_basic@read-crc-pipe-b.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-tgl-y/igt@kms_pipe_crc_basic@read-crc-pipe-b.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][21] ([i915#2203]) -> [PASS][22]
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-skl-guc/igt@vgem_basic@unload.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-skl-guc/igt@vgem_basic@unload.html
#### Warnings ####
* igt@gem_exec_suspend@basic-s3:
- fi-tgl-y: [DMESG-WARN][23] ([i915#2411] / [i915#402]) -> [DMESG-WARN][24] ([i915#2411])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/fi-tgl-y/igt@gem_exec_suspend@basic-s3.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/fi-tgl-y/igt@gem_exec_suspend@basic-s3.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#2411]: https://gitlab.freedesktop.org/drm/intel/issues/2411
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[k.org#205379]: https://bugzilla.kernel.org/show_bug.cgi?id=205379
Participating hosts (47 -> 41)
------------------------------
Missing (6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-bdw-samus
Build changes
-------------
* Linux: CI_DRM_9136 -> Patchwork_18691
CI-20190529: 20190529
CI_DRM_9136: 29eb1a8ba2cc0d14d3cae7213f9cdaaa13f3dd99 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5813: d4e6dd955a1dad02271aa41c9389f5097ee17765 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18691: 76dc916808f4d13e345da047cacc3f6fe4bdfe43 @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
76dc916808f4 drm/i915: Enable eLLC caching of display buffers for SKL+
3cf31e1a8caf drm/i915: Fix MOCS PTE setting for gen9+
331b6ff801c9 drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/index.html
[-- Attachment #1.2: Type: text/html, Size: 8014 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init (rev2)
2020-10-07 12:03 ` [Intel-gfx] " Ville Syrjala
` (5 preceding siblings ...)
(?)
@ 2020-10-14 14:23 ` Patchwork
-1 siblings, 0 replies; 13+ messages in thread
From: Patchwork @ 2020-10-14 14:23 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
[-- Attachment #1.1: Type: text/plain, Size: 13255 bytes --]
== Series Details ==
Series: series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init (rev2)
URL : https://patchwork.freedesktop.org/series/82438/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9136_full -> Patchwork_18691_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Known issues
------------
Here are the changes found in Patchwork_18691_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][1] -> [SKIP][2] ([i915#658])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-iclb2/igt@feature_discovery@psr2.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-iclb7/igt@feature_discovery@psr2.html
* igt@gem_userptr_blits@sync-unmap-cycles:
- shard-skl: [PASS][3] -> [TIMEOUT][4] ([i915#2424])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl8/igt@gem_userptr_blits@sync-unmap-cycles.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl5/igt@gem_userptr_blits@sync-unmap-cycles.html
* igt@i915_pm_dc@dc6-psr:
- shard-iclb: [PASS][5] -> [FAIL][6] ([i915#454])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-iclb1/igt@i915_pm_dc@dc6-psr.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-iclb6/igt@i915_pm_dc@dc6-psr.html
* igt@kms_cursor_edge_walk@pipe-a-128x128-top-edge:
- shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-snb2/igt@kms_cursor_edge_walk@pipe-a-128x128-top-edge.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-snb2/igt@kms_cursor_edge_walk@pipe-a-128x128-top-edge.html
* igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge:
- shard-skl: [PASS][9] -> [DMESG-WARN][10] ([i915#1982]) +10 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl5/igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl4/igt@kms_cursor_edge_walk@pipe-b-256x256-left-edge.html
* igt@kms_flip@flip-vs-expired-vblank@c-dp1:
- shard-apl: [PASS][11] -> [FAIL][12] ([i915#1635] / [i915#79])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-apl2/igt@kms_flip@flip-vs-expired-vblank@c-dp1.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-apl3/igt@kms_flip@flip-vs-expired-vblank@c-dp1.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt:
- shard-tglb: [PASS][13] -> [DMESG-WARN][14] ([i915#1982]) +2 similar issues
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-tglb5/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-tglb1/igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][15] -> [FAIL][16] ([i915#1188])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl2/igt@kms_hdr@bpc-switch-dpms.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl4/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min:
- shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145] / [i915#265])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl7/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl10/igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min.html
* igt@kms_psr@psr2_suspend:
- shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +2 similar issues
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-iclb2/igt@kms_psr@psr2_suspend.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-iclb4/igt@kms_psr@psr2_suspend.html
* igt@kms_setmode@basic:
- shard-skl: [PASS][21] -> [FAIL][22] ([i915#31])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl7/igt@kms_setmode@basic.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl10/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-c-query-busy:
- shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#1635] / [i915#1982])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-apl7/igt@kms_vblank@pipe-c-query-busy.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-apl7/igt@kms_vblank@pipe-c-query-busy.html
* igt@perf@polling-parameterized:
- shard-skl: [PASS][25] -> [FAIL][26] ([i915#1542])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl10/igt@perf@polling-parameterized.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl9/igt@perf@polling-parameterized.html
#### Possible fixes ####
* igt@gem_exec_fence@parallel@rcs0:
- shard-tglb: [FAIL][27] ([i915#1893]) -> [PASS][28]
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-tglb6/igt@gem_exec_fence@parallel@rcs0.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-tglb2/igt@gem_exec_fence@parallel@rcs0.html
* igt@gem_exec_reloc@basic-many-active@vecs0:
- shard-glk: [FAIL][29] ([i915#2389]) -> [PASS][30] +1 similar issue
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-glk7/igt@gem_exec_reloc@basic-many-active@vecs0.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-glk5/igt@gem_exec_reloc@basic-many-active@vecs0.html
* igt@gem_exec_whisper@basic-fds:
- shard-glk: [DMESG-WARN][31] ([i915#118] / [i915#95]) -> [PASS][32]
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-glk1/igt@gem_exec_whisper@basic-fds.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-glk1/igt@gem_exec_whisper@basic-fds.html
* igt@kms_big_fb@linear-32bpp-rotate-180:
- shard-skl: [DMESG-WARN][33] ([i915#1982]) -> [PASS][34] +12 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl5/igt@kms_big_fb@linear-32bpp-rotate-180.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl4/igt@kms_big_fb@linear-32bpp-rotate-180.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic:
- shard-skl: [FAIL][35] ([i915#2346]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl4/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl6/igt@kms_cursor_legacy@flip-vs-cursor-atomic.html
* igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1:
- shard-skl: [FAIL][37] ([i915#2122]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl9/igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl2/igt@kms_flip@plain-flip-ts-check-interruptible@b-edp1.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt:
- shard-kbl: [DMESG-WARN][39] ([i915#1982]) -> [PASS][40] +1 similar issue
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-kbl6/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-kbl7/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-plflip-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt:
- shard-tglb: [FAIL][41] -> [PASS][42] +2 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-tglb7/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-tglb6/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt:
- shard-tglb: [FAIL][43] ([i915#2416]) -> [PASS][44]
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-tglb5/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-kbl: [DMESG-WARN][45] ([i915#165] / [i915#78]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-kbl2/igt@kms_hdr@bpc-switch-dpms.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-kbl2/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [SKIP][47] ([fdo#109441]) -> [PASS][48]
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-iclb1/igt@kms_psr@psr2_cursor_mmap_cpu.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
* igt@kms_setmode@basic:
- shard-glk: [FAIL][49] ([i915#31]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-glk8/igt@kms_setmode@basic.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-glk9/igt@kms_setmode@basic.html
* igt@sysfs_heartbeat_interval@mixed@vcs1:
- shard-kbl: [INCOMPLETE][51] ([i915#1731]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-kbl4/igt@sysfs_heartbeat_interval@mixed@vcs1.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-kbl4/igt@sysfs_heartbeat_interval@mixed@vcs1.html
#### Warnings ####
* igt@i915_pm_rc6_residency@rc6-idle:
- shard-iclb: [FAIL][53] ([i915#1515]) -> [WARN][54] ([i915#1515])
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-iclb5/igt@i915_pm_rc6_residency@rc6-idle.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-iclb2/igt@i915_pm_rc6_residency@rc6-idle.html
* igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy:
- shard-skl: [DMESG-FAIL][55] ([i915#1982]) -> [DMESG-WARN][56] ([i915#1982])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9136/shard-skl1/igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/shard-skl1/igt@kms_cursor_legacy@flip-vs-cursor-crc-legacy.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[i915#118]: https://gitlab.freedesktop.org/drm/intel/issues/118
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1515]: https://gitlab.freedesktop.org/drm/intel/issues/1515
[i915#1542]: https://gitlab.freedesktop.org/drm/intel/issues/1542
[i915#1635]: https://gitlab.freedesktop.org/drm/intel/issues/1635
[i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165
[i915#1731]: https://gitlab.freedesktop.org/drm/intel/issues/1731
[i915#1893]: https://gitlab.freedesktop.org/drm/intel/issues/1893
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2122]: https://gitlab.freedesktop.org/drm/intel/issues/2122
[i915#2346]: https://gitlab.freedesktop.org/drm/intel/issues/2346
[i915#2389]: https://gitlab.freedesktop.org/drm/intel/issues/2389
[i915#2416]: https://gitlab.freedesktop.org/drm/intel/issues/2416
[i915#2424]: https://gitlab.freedesktop.org/drm/intel/issues/2424
[i915#2521]: https://gitlab.freedesktop.org/drm/intel/issues/2521
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
[i915#658]: https://gitlab.freedesktop.org/drm/intel/issues/658
[i915#78]: https://gitlab.freedesktop.org/drm/intel/issues/78
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (12 -> 11)
------------------------------
Missing (1): pig-snb-2600
Build changes
-------------
* Linux: CI_DRM_9136 -> Patchwork_18691
CI-20190529: 20190529
CI_DRM_9136: 29eb1a8ba2cc0d14d3cae7213f9cdaaa13f3dd99 @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5813: d4e6dd955a1dad02271aa41c9389f5097ee17765 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_18691: 76dc916808f4d13e345da047cacc3f6fe4bdfe43 @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18691/index.html
[-- Attachment #1.2: Type: text/html, Size: 15155 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-10-14 14:23 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-07 12:03 [PATCH 1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init Ville Syrjala
2020-10-07 12:03 ` [Intel-gfx] " Ville Syrjala
2020-10-07 12:03 ` [Intel-gfx] [PATCH 2/3] drm/i915: Fix MOCS PTE setting for gen9+ Ville Syrjala
2020-10-13 15:51 ` Chris Wilson
2020-10-13 16:11 ` Ville Syrjälä
2020-10-07 12:03 ` [Intel-gfx] [PATCH 3/3] drm/i915: Enable eLLC caching of display buffers for SKL+ Ville Syrjala
2020-10-07 13:37 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init Patchwork
2020-10-13 15:47 ` [PATCH 1/3] " Chris Wilson
2020-10-13 15:47 ` [Intel-gfx] " Chris Wilson
2020-10-13 16:12 ` Ville Syrjälä
2020-10-13 16:12 ` [Intel-gfx] " Ville Syrjälä
2020-10-13 19:15 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Mark ininitial fb obj as WT on eLLC machines to avoid rcu lockup during fbdev init (rev2) Patchwork
2020-10-14 14:23 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
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.