* [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
@ 2022-02-14 18:59 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-02-14 18:59 UTC (permalink / raw)
To: intel-gfx, dri-devel; +Cc: David Airlie, Thomas Gleixner
There are a few sections in the driver which are not compatible with
PREEMPT_RT. They trigger warnings and can lead to deadlocks at runtime.
Disable the i915 driver on a PREEMPT_RT enabled kernel. This way
PREEMPT_RT itself can be enabled without needing to address the i915
issues first. The RT related patches are still in RT queue and will be
handled later.
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
drivers/gpu/drm/i915/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index a4c94dc2e2164..3aa719d5a0f0d 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -3,6 +3,7 @@ config DRM_I915
tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics"
depends on DRM
depends on X86 && PCI
+ depends on !PREEMPT_RT
select INTEL_GTT
select INTERVAL_TREE
# we need shmfs for the swappable backing store, and in particular
--
2.34.1
^ permalink raw reply related [flat|nested] 18+ messages in thread
* [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Depend on !PREEMPT_RT.
2022-02-14 18:59 ` [Intel-gfx] " Sebastian Andrzej Siewior
(?)
@ 2022-02-16 3:16 ` Patchwork
-1 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2022-02-16 3:16 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 6601 bytes --]
== Series Details ==
Series: drm/i915: Depend on !PREEMPT_RT.
URL : https://patchwork.freedesktop.org/series/100121/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11230 -> Patchwork_22272
====================================================
Summary
-------
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/index.html
Participating hosts (49 -> 45)
------------------------------
Missing (4): fi-bsw-cyan shard-rkl fi-icl-u2 shard-tglu
Known issues
------------
Here are the changes found in Patchwork_22272 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_exec_suspend@basic-s3@smem:
- fi-bdw-5557u: [PASS][1] -> [INCOMPLETE][2] ([i915#146])
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/fi-bdw-5557u/igt@gem_exec_suspend@basic-s3@smem.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-bdw-5557u/igt@gem_exec_suspend@basic-s3@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-skl-6600u/igt@gem_huc_copy@huc-copy.html
* igt@gem_lmem_swapping@verify-random:
- fi-skl-6600u: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-skl-6600u/igt@gem_lmem_swapping@verify-random.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-soraka: [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/fi-kbl-soraka/igt@i915_pm_rpm@module-reload.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-kbl-soraka/igt@i915_pm_rpm@module-reload.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770: [PASS][7] -> [INCOMPLETE][8] ([i915#3303])
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-hsw-4770/igt@i915_selftest@live@hangcheck.html
* igt@kms_chamelium@vga-edid-read:
- fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-skl-6600u/igt@kms_chamelium@vga-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-skl-6600u: NOTRUN -> [SKIP][10] ([fdo#109271]) +2 similar issues
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-skl-6600u/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-skl-6600u: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#533])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-skl-6600u/igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_page_flip:
- fi-skl-6600u: NOTRUN -> [INCOMPLETE][12] ([i915#4547] / [i915#4838])
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-skl-6600u/igt@kms_psr@primary_page_flip.html
* igt@runner@aborted:
- fi-hsw-4770: NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#1436] / [i915#4312])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-hsw-4770/igt@runner@aborted.html
#### Possible fixes ####
* igt@gem_exec_suspend@basic-s3@smem:
- fi-skl-6600u: [INCOMPLETE][14] ([i915#4547]) -> [PASS][15]
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/fi-skl-6600u/igt@gem_exec_suspend@basic-s3@smem.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-skl-6600u/igt@gem_exec_suspend@basic-s3@smem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [DMESG-FAIL][16] ([i915#4957]) -> [PASS][17]
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/bat-dg1-6/igt@i915_selftest@live@hangcheck.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/bat-dg1-6/igt@i915_selftest@live@hangcheck.html
- bat-dg1-5: [DMESG-FAIL][18] ([i915#4494] / [i915#4957]) -> [PASS][19]
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/bat-dg1-5/igt@i915_selftest@live@hangcheck.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/bat-dg1-5/igt@i915_selftest@live@hangcheck.html
#### Warnings ####
* igt@runner@aborted:
- fi-skl-6600u: [FAIL][20] ([i915#4312]) -> [FAIL][21] ([i915#2722] / [i915#4312])
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/fi-skl-6600u/igt@runner@aborted.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/fi-skl-6600u/igt@runner@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4494]: https://gitlab.freedesktop.org/drm/intel/issues/4494
[i915#4547]: https://gitlab.freedesktop.org/drm/intel/issues/4547
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4838]: https://gitlab.freedesktop.org/drm/intel/issues/4838
[i915#4897]: https://gitlab.freedesktop.org/drm/intel/issues/4897
[i915#4957]: https://gitlab.freedesktop.org/drm/intel/issues/4957
[i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533
Build changes
-------------
* Linux: CI_DRM_11230 -> Patchwork_22272
CI-20190529: 20190529
CI_DRM_11230: e3741d576f60e3d0df5b385ba96a08ada3c760af @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_6345: ee18c0497ec2c74007e299c3fdd26f1613b9f514 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_22272: 41a5dcb2c41e17673eb548c07ecd6cd7124e0e0b @ git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
41a5dcb2c41e drm/i915: Depend on !PREEMPT_RT.
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/index.html
[-- Attachment #2: Type: text/html, Size: 8066 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Depend on !PREEMPT_RT.
2022-02-14 18:59 ` [Intel-gfx] " Sebastian Andrzej Siewior
(?)
(?)
@ 2022-02-16 7:16 ` Patchwork
-1 siblings, 0 replies; 18+ messages in thread
From: Patchwork @ 2022-02-16 7:16 UTC (permalink / raw)
To: Sebastian Siewior; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 30256 bytes --]
== Series Details ==
Series: drm/i915: Depend on !PREEMPT_RT.
URL : https://patchwork.freedesktop.org/series/100121/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11230_full -> Patchwork_22272_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
Participating hosts (13 -> 12)
------------------------------
Missing (1): shard-dg1
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_22272_full:
### IGT changes ###
#### Suppressed ####
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_balancer@sliced:
- {shard-rkl}: NOTRUN -> [INCOMPLETE][1] +1 similar issue
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-5/igt@gem_exec_balancer@sliced.html
Known issues
------------
Here are the changes found in Patchwork_22272_full that come from known issues:
### CI changes ###
#### Possible fixes ####
* boot:
- {shard-rkl}: ([PASS][2], [PASS][3], [PASS][4], [FAIL][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17]) -> ([PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37])
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-6/boot.html
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/boot.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/boot.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-2/boot.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-1/boot.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/boot.html
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/boot.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/boot.html
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-5/boot.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-5/boot.html
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-5/boot.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-5/boot.html
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-5/boot.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-5/boot.html
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-4/boot.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-4/boot.html
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-4/boot.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-2/boot.html
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-2/boot.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-1/boot.html
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-1/boot.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-1/boot.html
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-1/boot.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-1/boot.html
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-1/boot.html
### IGT changes ###
#### Issues hit ####
* igt@gem_create@create-massive:
- shard-apl: NOTRUN -> [DMESG-WARN][38] ([i915#4991])
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl6/igt@gem_create@create-massive.html
* igt@gem_eio@in-flight-10ms:
- shard-tglb: [PASS][39] -> [TIMEOUT][40] ([i915#3063])
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-tglb7/igt@gem_eio@in-flight-10ms.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb5/igt@gem_eio@in-flight-10ms.html
* igt@gem_eio@kms:
- shard-tglb: [PASS][41] -> [FAIL][42] ([i915#232])
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-tglb6/igt@gem_eio@kms.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@gem_eio@kms.html
* igt@gem_exec_capture@pi@rcs0:
- shard-skl: [PASS][43] -> [INCOMPLETE][44] ([i915#4547])
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-skl1/igt@gem_exec_capture@pi@rcs0.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl9/igt@gem_exec_capture@pi@rcs0.html
* igt@gem_exec_endless@dispatch@vecs0:
- shard-tglb: [PASS][45] -> [INCOMPLETE][46] ([i915#3778])
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-tglb7/igt@gem_exec_endless@dispatch@vecs0.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb1/igt@gem_exec_endless@dispatch@vecs0.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][47] -> [FAIL][48] ([i915#2842]) +1 similar issue
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-tglb1/igt@gem_exec_fair@basic-flow@rcs0.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb5/igt@gem_exec_fair@basic-flow@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-tglb: NOTRUN -> [FAIL][49] ([i915#2842])
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@gem_exec_fair@basic-none-solo@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-kbl: [PASS][50] -> [FAIL][51] ([i915#2842])
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-kbl4/igt@gem_exec_fair@basic-pace-solo@rcs0.html
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl1/igt@gem_exec_fair@basic-pace-solo@rcs0.html
* igt@gem_exec_whisper@basic-queues-all:
- shard-glk: [PASS][52] -> [DMESG-WARN][53] ([i915#118])
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk2/igt@gem_exec_whisper@basic-queues-all.html
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-glk4/igt@gem_exec_whisper@basic-queues-all.html
* igt@gem_lmem_swapping@heavy-random:
- shard-kbl: NOTRUN -> [SKIP][54] ([fdo#109271] / [i915#4613])
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl7/igt@gem_lmem_swapping@heavy-random.html
* igt@gem_userptr_blits@unsync-unmap-cycles:
- shard-iclb: NOTRUN -> [SKIP][55] ([i915#3297])
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb8/igt@gem_userptr_blits@unsync-unmap-cycles.html
* igt@gen3_mixed_blits:
- shard-tglb: NOTRUN -> [SKIP][56] ([fdo#109289])
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@gen3_mixed_blits.html
* igt@gen7_exec_parse@oacontrol-tracking:
- shard-iclb: NOTRUN -> [SKIP][57] ([fdo#109289]) +2 similar issues
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb8/igt@gen7_exec_parse@oacontrol-tracking.html
* igt@gen9_exec_parse@allowed-all:
- shard-apl: [PASS][58] -> [DMESG-WARN][59] ([i915#1436] / [i915#716])
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-apl4/igt@gen9_exec_parse@allowed-all.html
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl1/igt@gen9_exec_parse@allowed-all.html
* igt@gen9_exec_parse@allowed-single:
- shard-skl: NOTRUN -> [DMESG-WARN][60] ([i915#1436] / [i915#716])
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl10/igt@gen9_exec_parse@allowed-single.html
* igt@i915_pm_dc@dc6-dpms:
- shard-kbl: NOTRUN -> [FAIL][61] ([i915#454])
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl7/igt@i915_pm_dc@dc6-dpms.html
* igt@i915_selftest@live@hangcheck:
- shard-snb: [PASS][62] -> [INCOMPLETE][63] ([i915#3921])
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-snb4/igt@i915_selftest@live@hangcheck.html
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-snb2/igt@i915_selftest@live@hangcheck.html
* igt@i915_selftest@perf@region:
- shard-tglb: [PASS][64] -> [DMESG-WARN][65] ([i915#2867]) +1 similar issue
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-tglb8/igt@i915_selftest@perf@region.html
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb2/igt@i915_selftest@perf@region.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-apl: NOTRUN -> [SKIP][66] ([fdo#109271] / [i915#3777]) +4 similar issues
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl7/igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip:
- shard-skl: NOTRUN -> [FAIL][67] ([i915#3763])
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl7/igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip:
- shard-skl: NOTRUN -> [SKIP][68] ([fdo#109271] / [i915#3777]) +4 similar issues
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl7/igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-kbl: NOTRUN -> [SKIP][69] ([fdo#109271] / [i915#3886]) +2 similar issues
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl3/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][70] ([fdo#109271] / [i915#3886]) +6 similar issues
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl6/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc:
- shard-iclb: NOTRUN -> [SKIP][71] ([fdo#109278] / [i915#3886]) +2 similar issues
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb8/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-skl: NOTRUN -> [SKIP][72] ([fdo#109271] / [i915#3886]) +3 similar issues
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl6/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-d-ccs-on-another-bo-yf_tiled_ccs:
- shard-tglb: NOTRUN -> [SKIP][73] ([fdo#111615] / [i915#3689])
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@kms_ccs@pipe-d-ccs-on-another-bo-yf_tiled_ccs.html
* igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_ccs:
- shard-iclb: NOTRUN -> [SKIP][74] ([fdo#109278]) +4 similar issues
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb8/igt@kms_ccs@pipe-d-crc-primary-basic-y_tiled_ccs.html
* igt@kms_chamelium@hdmi-cmp-planar-formats:
- shard-iclb: NOTRUN -> [SKIP][75] ([fdo#109284] / [fdo#111827]) +1 similar issue
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb8/igt@kms_chamelium@hdmi-cmp-planar-formats.html
* igt@kms_chamelium@vga-hpd:
- shard-apl: NOTRUN -> [SKIP][76] ([fdo#109271] / [fdo#111827]) +5 similar issues
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl7/igt@kms_chamelium@vga-hpd.html
* igt@kms_color_chamelium@pipe-d-ctm-blue-to-red:
- shard-skl: NOTRUN -> [SKIP][77] ([fdo#109271] / [fdo#111827]) +8 similar issues
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl10/igt@kms_color_chamelium@pipe-d-ctm-blue-to-red.html
* igt@kms_color_chamelium@pipe-d-ctm-max:
- shard-kbl: NOTRUN -> [SKIP][78] ([fdo#109271] / [fdo#111827]) +3 similar issues
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl3/igt@kms_color_chamelium@pipe-d-ctm-max.html
* igt@kms_content_protection@atomic:
- shard-kbl: NOTRUN -> [TIMEOUT][79] ([i915#1319])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl3/igt@kms_content_protection@atomic.html
* igt@kms_content_protection@lic:
- shard-apl: NOTRUN -> [TIMEOUT][80] ([i915#1319])
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl4/igt@kms_content_protection@lic.html
* igt@kms_cursor_crc@pipe-c-cursor-suspend:
- shard-apl: [PASS][81] -> [DMESG-WARN][82] ([i915#180])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-apl3/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl6/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
* igt@kms_cursor_crc@pipe-d-cursor-256x85-rapid-movement:
- shard-skl: NOTRUN -> [SKIP][83] ([fdo#109271] / [i915#1888])
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl10/igt@kms_cursor_crc@pipe-d-cursor-256x85-rapid-movement.html
* igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic:
- shard-iclb: NOTRUN -> [SKIP][84] ([fdo#109274] / [fdo#109278])
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb8/igt@kms_cursor_legacy@2x-long-nonblocking-modeset-vs-cursor-atomic.html
* igt@kms_cursor_legacy@pipe-d-torture-bo:
- shard-apl: NOTRUN -> [SKIP][85] ([fdo#109271] / [i915#533]) +1 similar issue
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl7/igt@kms_cursor_legacy@pipe-d-torture-bo.html
* igt@kms_flip@2x-dpms-vs-vblank-race-interruptible:
- shard-tglb: NOTRUN -> [SKIP][86] ([fdo#109274] / [fdo#111825]) +1 similar issue
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@kms_flip@2x-dpms-vs-vblank-race-interruptible.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
- shard-kbl: [PASS][87] -> [DMESG-WARN][88] ([i915#180]) +4 similar issues
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-kbl6/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl4/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-edp1:
- shard-tglb: [PASS][89] -> [DMESG-WARN][90] ([i915#2411] / [i915#2867])
[89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-tglb8/igt@kms_flip@flip-vs-suspend-interruptible@c-edp1.html
[90]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb2/igt@kms_flip@flip-vs-suspend-interruptible@c-edp1.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt:
- shard-kbl: NOTRUN -> [SKIP][91] ([fdo#109271]) +55 similar issues
[91]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl7/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-cur-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt:
- shard-skl: NOTRUN -> [SKIP][92] ([fdo#109271]) +72 similar issues
[92]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl10/igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-iclb: NOTRUN -> [SKIP][93] ([fdo#109280]) +2 similar issues
[93]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb8/igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-blt:
- shard-tglb: NOTRUN -> [SKIP][94] ([fdo#109280] / [fdo#111825]) +1 similar issue
[94]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@kms_frontbuffer_tracking@psr-2p-primscrn-pri-indfb-draw-blt.html
* igt@kms_hdr@bpc-switch-dpms:
- shard-skl: [PASS][95] -> [FAIL][96] ([i915#1188])
[95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-skl1/igt@kms_hdr@bpc-switch-dpms.html
[96]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl4/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_pipe_b_c_ivb@disable-pipe-b-enable-pipe-c:
- shard-apl: NOTRUN -> [SKIP][97] ([fdo#109271]) +79 similar issues
[97]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl7/igt@kms_pipe_b_c_ivb@disable-pipe-b-enable-pipe-c.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d:
- shard-skl: NOTRUN -> [SKIP][98] ([fdo#109271] / [i915#533]) +1 similar issue
[98]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl10/igt@kms_pipe_crc_basic@suspend-read-crc-pipe-d.html
* igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
- shard-apl: NOTRUN -> [FAIL][99] ([fdo#108145] / [i915#265])
[99]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl7/igt@kms_plane_alpha_blend@pipe-a-alpha-7efc.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max:
- shard-skl: NOTRUN -> [FAIL][100] ([fdo#108145] / [i915#265]) +1 similar issue
[100]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl6/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-max.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [PASS][101] -> [FAIL][102] ([fdo#108145] / [i915#265])
[101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-skl7/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[102]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb:
- shard-apl: NOTRUN -> [FAIL][103] ([i915#265])
[103]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl4/igt@kms_plane_alpha_blend@pipe-b-alpha-transparent-fb.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-kbl: NOTRUN -> [FAIL][104] ([fdo#108145] / [i915#265])
[104]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl7/igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max.html
* igt@kms_plane_lowres@pipe-b-tiling-y:
- shard-tglb: NOTRUN -> [SKIP][105] ([i915#3536])
[105]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@kms_plane_lowres@pipe-b-tiling-y.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-skl: NOTRUN -> [SKIP][106] ([fdo#109271] / [i915#658]) +1 similar issue
[106]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl6/igt@kms_psr2_sf@primary-plane-update-sf-dmg-area.html
* igt@kms_psr@psr2_no_drrs:
- shard-tglb: NOTRUN -> [FAIL][107] ([i915#132] / [i915#3467])
[107]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@kms_psr@psr2_no_drrs.html
* igt@kms_psr@psr2_sprite_mmap_cpu:
- shard-iclb: [PASS][108] -> [SKIP][109] ([fdo#109441])
[108]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html
[109]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb3/igt@kms_psr@psr2_sprite_mmap_cpu.html
* igt@kms_setmode@basic:
- shard-glk: [PASS][110] -> [FAIL][111] ([i915#31])
[110]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk7/igt@kms_setmode@basic.html
[111]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-glk3/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-kbl: [PASS][112] -> [DMESG-WARN][113] ([i915#180] / [i915#295])
[112]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[113]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-kbl6/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@nouveau_crc@pipe-a-source-outp-inactive:
- shard-iclb: NOTRUN -> [SKIP][114] ([i915#2530])
[114]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb8/igt@nouveau_crc@pipe-a-source-outp-inactive.html
* igt@nouveau_crc@pipe-c-source-outp-inactive:
- shard-tglb: NOTRUN -> [SKIP][115] ([i915#2530])
[115]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb8/igt@nouveau_crc@pipe-c-source-outp-inactive.html
* igt@sysfs_clients@pidname:
- shard-apl: NOTRUN -> [SKIP][116] ([fdo#109271] / [i915#2994]) +1 similar issue
[116]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl6/igt@sysfs_clients@pidname.html
#### Possible fixes ####
* igt@api_intel_allocator@two-level-inception-interruptible:
- {shard-rkl}: [INCOMPLETE][117] -> [PASS][118]
[117]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@api_intel_allocator@two-level-inception-interruptible.html
[118]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-5/igt@api_intel_allocator@two-level-inception-interruptible.html
* igt@feature_discovery@psr2:
- {shard-rkl}: [SKIP][119] ([i915#658]) -> [PASS][120]
[119]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@feature_discovery@psr2.html
[120]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@feature_discovery@psr2.html
* igt@gem_ctx_isolation@dirty-switch@vecs0:
- {shard-rkl}: [DMESG-WARN][121] -> [PASS][122] +1 similar issue
[121]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@gem_ctx_isolation@dirty-switch@vecs0.html
[122]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-2/igt@gem_ctx_isolation@dirty-switch@vecs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [FAIL][123] ([i915#2842]) -> [PASS][124]
[123]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-tglb7/igt@gem_exec_fair@basic-pace-share@rcs0.html
[124]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-tglb7/igt@gem_exec_fair@basic-pace-share@rcs0.html
* igt@gem_exec_whisper@basic-queues-priority-all:
- {shard-rkl}: [INCOMPLETE][125] ([i915#5080]) -> [PASS][126]
[125]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@gem_exec_whisper@basic-queues-priority-all.html
[126]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@gem_exec_whisper@basic-queues-priority-all.html
* igt@kms_atomic@plane-primary-legacy:
- {shard-rkl}: [SKIP][127] ([i915#1845]) -> [PASS][128] +8 similar issues
[127]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@kms_atomic@plane-primary-legacy.html
[128]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@kms_atomic@plane-primary-legacy.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-180:
- shard-glk: [DMESG-WARN][129] ([i915#118]) -> [PASS][130]
[129]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk8/igt@kms_big_fb@x-tiled-32bpp-rotate-180.html
[130]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-glk7/igt@kms_big_fb@x-tiled-32bpp-rotate-180.html
* igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc:
- {shard-rkl}: [SKIP][131] ([i915#1845] / [i915#4098]) -> [PASS][132]
[131]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html
[132]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_color@pipe-a-degamma:
- {shard-rkl}: ([SKIP][133], [SKIP][134]) ([i915#1149] / [i915#1849] / [i915#4098]) -> [PASS][135]
[133]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-4/igt@kms_color@pipe-a-degamma.html
[134]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@kms_color@pipe-a-degamma.html
[135]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@kms_color@pipe-a-degamma.html
* igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement:
- {shard-rkl}: [SKIP][136] ([fdo#112022]) -> [PASS][137] +2 similar issues
[136]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement.html
[137]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@kms_cursor_crc@pipe-a-cursor-128x128-rapid-movement.html
* igt@kms_cursor_legacy@cursor-vs-flip-atomic:
- {shard-rkl}: [SKIP][138] ([fdo#111825]) -> [PASS][139]
[138]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@kms_cursor_legacy@cursor-vs-flip-atomic.html
[139]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@kms_cursor_legacy@cursor-vs-flip-atomic.html
* igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-skl: [FAIL][140] ([i915#2346]) -> [PASS][141]
[140]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-skl2/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
[141]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl7/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
* igt@kms_cursor_legacy@flip-vs-cursor-toggle:
- shard-iclb: [FAIL][142] ([i915#2346]) -> [PASS][143]
[142]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
[143]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb6/igt@kms_cursor_legacy@flip-vs-cursor-toggle.html
* igt@kms_dp_aux_dev:
- {shard-rkl}: [SKIP][144] ([i915#1257]) -> [PASS][145]
[144]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@kms_dp_aux_dev.html
[145]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@kms_dp_aux_dev.html
* igt@kms_draw_crc@draw-method-xrgb8888-mmap-gtt-xtiled:
- {shard-rkl}: [SKIP][146] ([fdo#111314]) -> [PASS][147] +1 similar issue
[146]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-rkl-5/igt@kms_draw_crc@draw-method-xrgb8888-mmap-gtt-xtiled.html
[147]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-rkl-6/igt@kms_draw_crc@draw-method-xrgb8888-mmap-gtt-xtiled.html
* igt@kms_flip@dpms-off-confusion-interruptible@a-edp1:
- shard-skl: [DMESG-WARN][148] ([i915#1982]) -> [PASS][149]
[148]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-skl1/igt@kms_flip@dpms-off-confusion-interruptible@a-edp1.html
[149]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl6/igt@kms_flip@dpms-off-confusion-interruptible@a-edp1.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1:
- shard-skl: [FAIL][150] ([i915#2122]) -> [PASS][151]
[150]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
[151]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-skl7/igt@kms_flip@flip-vs-expired-vblank-interruptible@a-edp1.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a2:
- shard-glk: [FAIL][152] ([i915#79]) -> [PASS][153]
[152]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-glk8/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a2.html
[153]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-glk1/igt@kms_flip@flip-vs-expired-vblank-interruptible@b-hdmi-a2.html
* igt@kms_flip@flip-vs-suspend-interruptible@c-dp1:
- shard-apl: [DMESG-WARN][154] ([i915#180]) -> [PASS][155] +5 similar issues
[154]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
[155]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible@c-dp1.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling:
- shard-iclb: [SKIP][156] ([i915#3701]) -> [PASS][157]
[156]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11230/shard-iclb2/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html
[157]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/shard-iclb3/igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile-downscaling.html
* igt@kms_frontbuffer_track
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_22272/index.html
[-- Attachment #2: Type: text/html, Size: 33582 bytes --]
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: [PATCH] drm/i915: Depend on !PREEMPT_RT.
2022-02-14 18:59 ` [Intel-gfx] " Sebastian Andrzej Siewior
@ 2022-02-25 23:03 ` Sebastian Andrzej Siewior
-1 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-02-25 23:03 UTC (permalink / raw)
To: intel-gfx, dri-devel
Cc: David Airlie, Tvrtko Ursulin, Thomas Gleixner, Rodrigo Vivi
On 2022-02-14 19:59:08 [+0100], To intel-gfx@lists.freedesktop.org wrote:
> There are a few sections in the driver which are not compatible with
> PREEMPT_RT. They trigger warnings and can lead to deadlocks at runtime.
>
> Disable the i915 driver on a PREEMPT_RT enabled kernel. This way
> PREEMPT_RT itself can be enabled without needing to address the i915
> issues first. The RT related patches are still in RT queue and will be
> handled later.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
A gentle ping ;)
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index a4c94dc2e2164..3aa719d5a0f0d 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -3,6 +3,7 @@ config DRM_I915
> tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics"
> depends on DRM
> depends on X86 && PCI
> + depends on !PREEMPT_RT
> select INTEL_GTT
> select INTERVAL_TREE
> # we need shmfs for the swappable backing store, and in particular
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
@ 2022-02-25 23:03 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-02-25 23:03 UTC (permalink / raw)
To: intel-gfx, dri-devel; +Cc: David Airlie, Thomas Gleixner, Rodrigo Vivi
On 2022-02-14 19:59:08 [+0100], To intel-gfx@lists.freedesktop.org wrote:
> There are a few sections in the driver which are not compatible with
> PREEMPT_RT. They trigger warnings and can lead to deadlocks at runtime.
>
> Disable the i915 driver on a PREEMPT_RT enabled kernel. This way
> PREEMPT_RT itself can be enabled without needing to address the i915
> issues first. The RT related patches are still in RT queue and will be
> handled later.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
A gentle ping ;)
> ---
> drivers/gpu/drm/i915/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index a4c94dc2e2164..3aa719d5a0f0d 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -3,6 +3,7 @@ config DRM_I915
> tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics"
> depends on DRM
> depends on X86 && PCI
> + depends on !PREEMPT_RT
> select INTEL_GTT
> select INTERVAL_TREE
> # we need shmfs for the swappable backing store, and in particular
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/i915: Depend on !PREEMPT_RT.
2022-02-25 23:03 ` [Intel-gfx] " Sebastian Andrzej Siewior
@ 2022-02-28 10:10 ` Tvrtko Ursulin
-1 siblings, 0 replies; 18+ messages in thread
From: Tvrtko Ursulin @ 2022-02-28 10:10 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, intel-gfx, dri-devel
Cc: David Airlie, Thomas Gleixner, Rodrigo Vivi
Hi,
On 25/02/2022 23:03, Sebastian Andrzej Siewior wrote:
> On 2022-02-14 19:59:08 [+0100], To intel-gfx@lists.freedesktop.org wrote:
>> There are a few sections in the driver which are not compatible with
>> PREEMPT_RT. They trigger warnings and can lead to deadlocks at runtime.
>>
>> Disable the i915 driver on a PREEMPT_RT enabled kernel. This way
>> PREEMPT_RT itself can be enabled without needing to address the i915
>> issues first. The RT related patches are still in RT queue and will be
>> handled later.
>>
>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> A gentle ping ;)
Could you paste a link to the queue of i915 patches pending for a quick
overview of how much work there is and in what areas?
Also, I assume due absence of ARCH_SUPPORTS_RT being defined by any
arch, that something more is not yet ready?
Regards,
Tvrtko
>> ---
>> drivers/gpu/drm/i915/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index a4c94dc2e2164..3aa719d5a0f0d 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -3,6 +3,7 @@ config DRM_I915
>> tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics"
>> depends on DRM
>> depends on X86 && PCI
>> + depends on !PREEMPT_RT
>> select INTEL_GTT
>> select INTERVAL_TREE
>> # we need shmfs for the swappable backing store, and in particular
>
> Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
@ 2022-02-28 10:10 ` Tvrtko Ursulin
0 siblings, 0 replies; 18+ messages in thread
From: Tvrtko Ursulin @ 2022-02-28 10:10 UTC (permalink / raw)
To: Sebastian Andrzej Siewior, intel-gfx, dri-devel
Cc: David Airlie, Thomas Gleixner, Rodrigo Vivi
Hi,
On 25/02/2022 23:03, Sebastian Andrzej Siewior wrote:
> On 2022-02-14 19:59:08 [+0100], To intel-gfx@lists.freedesktop.org wrote:
>> There are a few sections in the driver which are not compatible with
>> PREEMPT_RT. They trigger warnings and can lead to deadlocks at runtime.
>>
>> Disable the i915 driver on a PREEMPT_RT enabled kernel. This way
>> PREEMPT_RT itself can be enabled without needing to address the i915
>> issues first. The RT related patches are still in RT queue and will be
>> handled later.
>>
>> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>
> A gentle ping ;)
Could you paste a link to the queue of i915 patches pending for a quick
overview of how much work there is and in what areas?
Also, I assume due absence of ARCH_SUPPORTS_RT being defined by any
arch, that something more is not yet ready?
Regards,
Tvrtko
>> ---
>> drivers/gpu/drm/i915/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index a4c94dc2e2164..3aa719d5a0f0d 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -3,6 +3,7 @@ config DRM_I915
>> tristate "Intel 8xx/9xx/G3x/G4x/HD Graphics"
>> depends on DRM
>> depends on X86 && PCI
>> + depends on !PREEMPT_RT
>> select INTEL_GTT
>> select INTERVAL_TREE
>> # we need shmfs for the swappable backing store, and in particular
>
> Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/i915: Depend on !PREEMPT_RT.
2022-02-28 10:10 ` [Intel-gfx] " Tvrtko Ursulin
@ 2022-02-28 10:35 ` Sebastian Andrzej Siewior
-1 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-02-28 10:35 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 2022-02-28 10:10:48 [+0000], Tvrtko Ursulin wrote:
> Hi,
Hi,
> Could you paste a link to the queue of i915 patches pending for a quick
> overview of how much work there is and in what areas?
Last post to the list:
https://https://lkml.kernel.org/r/.kernel.org/all/20211214140301.520464-1-bigeasy@linutronix.de/
or if you look at the DRM section in
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/series?h=v5.17-rc6-rt10-patches#n156
you see:
0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
0010-drm-i915-Drop-the-irqs_disabled-check.patch
Revert-drm-i915-Depend-on-PREEMPT_RT.patch
and you could view them from
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches?h=v5.17-rc6-rt10-patches
> Also, I assume due absence of ARCH_SUPPORTS_RT being defined by any arch,
> that something more is not yet ready?
Correct. Looking at what I have queued for the next merge window I have
less than 20 patches (excluding i915 and printk) before ARCH_SUPPORTS_RT
can be enabled for x86-64.
> Regards,
>
> Tvrtko
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
@ 2022-02-28 10:35 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-02-28 10:35 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 2022-02-28 10:10:48 [+0000], Tvrtko Ursulin wrote:
> Hi,
Hi,
> Could you paste a link to the queue of i915 patches pending for a quick
> overview of how much work there is and in what areas?
Last post to the list:
https://https://lkml.kernel.org/r/.kernel.org/all/20211214140301.520464-1-bigeasy@linutronix.de/
or if you look at the DRM section in
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/series?h=v5.17-rc6-rt10-patches#n156
you see:
0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
0010-drm-i915-Drop-the-irqs_disabled-check.patch
Revert-drm-i915-Depend-on-PREEMPT_RT.patch
and you could view them from
https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches?h=v5.17-rc6-rt10-patches
> Also, I assume due absence of ARCH_SUPPORTS_RT being defined by any arch,
> that something more is not yet ready?
Correct. Looking at what I have queued for the next merge window I have
less than 20 patches (excluding i915 and printk) before ARCH_SUPPORTS_RT
can be enabled for x86-64.
> Regards,
>
> Tvrtko
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/i915: Depend on !PREEMPT_RT.
2022-02-28 10:35 ` [Intel-gfx] " Sebastian Andrzej Siewior
@ 2022-03-01 14:27 ` Tvrtko Ursulin
-1 siblings, 0 replies; 18+ messages in thread
From: Tvrtko Ursulin @ 2022-03-01 14:27 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 28/02/2022 10:35, Sebastian Andrzej Siewior wrote:
> On 2022-02-28 10:10:48 [+0000], Tvrtko Ursulin wrote:
>> Hi,
> Hi,
>
>> Could you paste a link to the queue of i915 patches pending for a quick
>> overview of how much work there is and in what areas?
>
> Last post to the list:
> https://https://lkml.kernel.org/r/.kernel.org/all/20211214140301.520464-1-bigeasy@linutronix.de/
>
> or if you look at the DRM section in
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/series?h=v5.17-rc6-rt10-patches#n156
Thanks!
> you see:
> 0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
> 0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
Two for the display folks.
> 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
solution could be to always force the !ATOMIC path (for the whole
_wait_for_atomic macro) on PREEMPT_RT.
> 0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
If the issue is only with certain trace points why disable all?
> 0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
Didn't quite fully understand, why is this not fixable? Especially
thinking if the option of not blanket disabling all tracepoints in the
previous patch.
> 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
Not sure about why cond_resched was put between irq_work_queue and
irq_work_sync - would it not be like-for-like change to have the two
together? Commit message makes me think _queue already starts the
handler on x86 at least.
> 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
I think this is okay. The part after the unlock is serialized by the
tasklet already.
Slight doubt due the comment:
local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
Makes me want to think about it harder but not now.
Another thing to check is if execlists_context_status_change still needs
the atomic notifier chain with this change.
> 0010-drm-i915-Drop-the-irqs_disabled-check.patch
LGTM.
> Revert-drm-i915-Depend-on-PREEMPT_RT.patch
Okay.
And finally for this very patch (the thread I am replying to):
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
>
> and you could view them from
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches?h=v5.17-rc6-rt10-patches
>
>> Also, I assume due absence of ARCH_SUPPORTS_RT being defined by any arch,
>> that something more is not yet ready?
>
> Correct. Looking at what I have queued for the next merge window I have
> less than 20 patches (excluding i915 and printk) before ARCH_SUPPORTS_RT
> can be enabled for x86-64.
>
>> Regards,
>>
>> Tvrtko
>
> Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
@ 2022-03-01 14:27 ` Tvrtko Ursulin
0 siblings, 0 replies; 18+ messages in thread
From: Tvrtko Ursulin @ 2022-03-01 14:27 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 28/02/2022 10:35, Sebastian Andrzej Siewior wrote:
> On 2022-02-28 10:10:48 [+0000], Tvrtko Ursulin wrote:
>> Hi,
> Hi,
>
>> Could you paste a link to the queue of i915 patches pending for a quick
>> overview of how much work there is and in what areas?
>
> Last post to the list:
> https://https://lkml.kernel.org/r/.kernel.org/all/20211214140301.520464-1-bigeasy@linutronix.de/
>
> or if you look at the DRM section in
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches/series?h=v5.17-rc6-rt10-patches#n156
Thanks!
> you see:
> 0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
> 0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
Two for the display folks.
> 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
solution could be to always force the !ATOMIC path (for the whole
_wait_for_atomic macro) on PREEMPT_RT.
> 0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
If the issue is only with certain trace points why disable all?
> 0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
Didn't quite fully understand, why is this not fixable? Especially
thinking if the option of not blanket disabling all tracepoints in the
previous patch.
> 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
Not sure about why cond_resched was put between irq_work_queue and
irq_work_sync - would it not be like-for-like change to have the two
together? Commit message makes me think _queue already starts the
handler on x86 at least.
> 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
I think this is okay. The part after the unlock is serialized by the
tasklet already.
Slight doubt due the comment:
local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
Makes me want to think about it harder but not now.
Another thing to check is if execlists_context_status_change still needs
the atomic notifier chain with this change.
> 0010-drm-i915-Drop-the-irqs_disabled-check.patch
LGTM.
> Revert-drm-i915-Depend-on-PREEMPT_RT.patch
Okay.
And finally for this very patch (the thread I am replying to):
Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Regards,
Tvrtko
>
> and you could view them from
> https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git/tree/patches?h=v5.17-rc6-rt10-patches
>
>> Also, I assume due absence of ARCH_SUPPORTS_RT being defined by any arch,
>> that something more is not yet ready?
>
> Correct. Looking at what I have queued for the next merge window I have
> less than 20 patches (excluding i915 and printk) before ARCH_SUPPORTS_RT
> can be enabled for x86-64.
>
>> Regards,
>>
>> Tvrtko
>
> Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/i915: Depend on !PREEMPT_RT.
2022-03-01 14:27 ` [Intel-gfx] " Tvrtko Ursulin
@ 2022-03-01 15:13 ` Sebastian Andrzej Siewior
-1 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-03-01 15:13 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 2022-03-01 14:27:18 [+0000], Tvrtko Ursulin wrote:
> > you see:
> > 0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
> > 0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
>
> Two for the display folks.
>
> > 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
>
> What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
> solution could be to always force the !ATOMIC path (for the whole
> _wait_for_atomic macro) on PREEMPT_RT.
Could be one way to handle it. But please don't disable preemption and
or interrupts for longer period of time as all of it increases the
overall latency.
Side note: All of these patches is a collection over time. I personally
have only a single i7-sandybridge with i915 and here I don't really
enter all the possible paths here. People report, I patch and look
around and then they are quiet so I assume that it is working.
> > 0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
>
> If the issue is only with certain trace points why disable all?
It is a class and it is easier that way.
> > 0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
>
> Didn't quite fully understand, why is this not fixable? Especially thinking
> if the option of not blanket disabling all tracepoints in the previous
> patch.
The problem is that you can't acquire that lock from within that
trace-point on PREEMPT_RT. On !RT it is possible but it is also
problematic because LOCKDEP does not see possible dead locks unless that
trace-point is enabled.
I've been talking to Steven (after
https://lkml.kernel.org/r/20211214115837.6f33a9b2@gandalf.local.home)
and he wants to come up with something where you can pass a lock as
argument to the tracing-API. That way the lock can be acquired before
the trace event is invoked and lockdep will see it even if the trace
event is disabled.
So there is an idea how to get it to work eventually without disabling
it in the long term.
Making the register a raw_spinlock_t would solve problem immediately but
I am a little worried given the increased latency in a quick test:
https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
also, this one single hardware but the upper limit atomic-polls is high.
> > 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
>
> Not sure about why cond_resched was put between irq_work_queue and
> irq_work_sync - would it not be like-for-like change to have the two
> together?
maybe it loops for a while and an additional scheduling would be nice.
> Commit message makes me think _queue already starts the handler on
> x86 at least.
Yes, irq_work_queue() triggers the IRQ right away on x86,
irq_work_sync() would wait for it to happen in case it did not happen.
On architectures which don't provide an IRQ-work interrupt, it is
delayed to the HZ tick timer interrupt. So this serves also as an
example in case someone want to copy the code ;)
> > 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
>
> I think this is okay. The part after the unlock is serialized by the tasklet
> already.
>
> Slight doubt due the comment:
>
> local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
>
> Makes me want to think about it harder but not now.
Clark reported it and confirmed that the warning is gone on RT and
everything appears to work ;)
PREEMPT_RT wise there is no synchronisation vs irq_work other than an
actual lock (in case it is needed).
> Another thing to check is if execlists_context_status_change still needs the
> atomic notifier chain with this change.
>
> > 0010-drm-i915-Drop-the-irqs_disabled-check.patch
>
> LGTM.
Do you want me to repost that one?
> > Revert-drm-i915-Depend-on-PREEMPT_RT.patch
>
> Okay.
>
> And finally for this very patch (the thread I am replying to):
>
> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Thanks.
> Regards,
>
> Tvrtko
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
@ 2022-03-01 15:13 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-03-01 15:13 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 2022-03-01 14:27:18 [+0000], Tvrtko Ursulin wrote:
> > you see:
> > 0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
> > 0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
>
> Two for the display folks.
>
> > 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
>
> What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
> solution could be to always force the !ATOMIC path (for the whole
> _wait_for_atomic macro) on PREEMPT_RT.
Could be one way to handle it. But please don't disable preemption and
or interrupts for longer period of time as all of it increases the
overall latency.
Side note: All of these patches is a collection over time. I personally
have only a single i7-sandybridge with i915 and here I don't really
enter all the possible paths here. People report, I patch and look
around and then they are quiet so I assume that it is working.
> > 0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
>
> If the issue is only with certain trace points why disable all?
It is a class and it is easier that way.
> > 0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
>
> Didn't quite fully understand, why is this not fixable? Especially thinking
> if the option of not blanket disabling all tracepoints in the previous
> patch.
The problem is that you can't acquire that lock from within that
trace-point on PREEMPT_RT. On !RT it is possible but it is also
problematic because LOCKDEP does not see possible dead locks unless that
trace-point is enabled.
I've been talking to Steven (after
https://lkml.kernel.org/r/20211214115837.6f33a9b2@gandalf.local.home)
and he wants to come up with something where you can pass a lock as
argument to the tracing-API. That way the lock can be acquired before
the trace event is invoked and lockdep will see it even if the trace
event is disabled.
So there is an idea how to get it to work eventually without disabling
it in the long term.
Making the register a raw_spinlock_t would solve problem immediately but
I am a little worried given the increased latency in a quick test:
https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
also, this one single hardware but the upper limit atomic-polls is high.
> > 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
>
> Not sure about why cond_resched was put between irq_work_queue and
> irq_work_sync - would it not be like-for-like change to have the two
> together?
maybe it loops for a while and an additional scheduling would be nice.
> Commit message makes me think _queue already starts the handler on
> x86 at least.
Yes, irq_work_queue() triggers the IRQ right away on x86,
irq_work_sync() would wait for it to happen in case it did not happen.
On architectures which don't provide an IRQ-work interrupt, it is
delayed to the HZ tick timer interrupt. So this serves also as an
example in case someone want to copy the code ;)
> > 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
>
> I think this is okay. The part after the unlock is serialized by the tasklet
> already.
>
> Slight doubt due the comment:
>
> local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
>
> Makes me want to think about it harder but not now.
Clark reported it and confirmed that the warning is gone on RT and
everything appears to work ;)
PREEMPT_RT wise there is no synchronisation vs irq_work other than an
actual lock (in case it is needed).
> Another thing to check is if execlists_context_status_change still needs the
> atomic notifier chain with this change.
>
> > 0010-drm-i915-Drop-the-irqs_disabled-check.patch
>
> LGTM.
Do you want me to repost that one?
> > Revert-drm-i915-Depend-on-PREEMPT_RT.patch
>
> Okay.
>
> And finally for this very patch (the thread I am replying to):
>
> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Thanks.
> Regards,
>
> Tvrtko
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/i915: Depend on !PREEMPT_RT.
2022-03-01 15:13 ` [Intel-gfx] " Sebastian Andrzej Siewior
@ 2022-03-02 11:42 ` Tvrtko Ursulin
-1 siblings, 0 replies; 18+ messages in thread
From: Tvrtko Ursulin @ 2022-03-02 11:42 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 01/03/2022 15:13, Sebastian Andrzej Siewior wrote:
> On 2022-03-01 14:27:18 [+0000], Tvrtko Ursulin wrote:
>>> you see:
>>> 0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
>>> 0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
>>
>> Two for the display folks.
>>
>>> 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
>>
>> What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
>> solution could be to always force the !ATOMIC path (for the whole
>> _wait_for_atomic macro) on PREEMPT_RT.
>
> Could be one way to handle it. But please don't disable preemption and
> or interrupts for longer period of time as all of it increases the
> overall latency.
I am looking for your guidance of what is the correct thing here.
Main purpose of this macro on the i915 side is to do short waits on GPU
registers changing post write from spin-locked sections. But there were
rare cases when very short waits were needed from unlocked sections,
shorter than 10us (which is AFAIR what usleep_range documents should be
a lower limit). Which is why non-atomic path was added to the macro.
That path uses preempt_disable/enable so it can use local_clock().
All this may, or may not be, compatible with PREEMPT_RT to start with?
Or question phrased differently, how we should implement the <10us waits
from non-atomic sections under PREEMPT_RT?
> Side note: All of these patches is a collection over time. I personally
> have only a single i7-sandybridge with i915 and here I don't really
> enter all the possible paths here. People report, I patch and look
> around and then they are quiet so I assume that it is working.
>
>>> 0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
>>
>> If the issue is only with certain trace points why disable all?
>
> It is a class and it is easier that way.
>
>>> 0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
>>
>> Didn't quite fully understand, why is this not fixable? Especially thinking
>> if the option of not blanket disabling all tracepoints in the previous
>> patch.
>
> The problem is that you can't acquire that lock from within that
> trace-point on PREEMPT_RT. On !RT it is possible but it is also
> problematic because LOCKDEP does not see possible dead locks unless that
> trace-point is enabled.
Oh I meant could the include ordering problem be fixed differently?
"""
[PATCH 07/10] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with
NOTRACE
The order of the header files is important. If this header file is
included after tracepoint.h was included then the NOTRACE here becomes a
nop. Currently this happens for two .c files which use the tracepoitns
behind DRM_I915_LOW_LEVEL_TRACEPOINTS.
"""
Like these two .c files - can order of includes just be changed in them?
>
> I've been talking to Steven (after
> https://lkml.kernel.org/r/20211214115837.6f33a9b2@gandalf.local.home)
> and he wants to come up with something where you can pass a lock as
> argument to the tracing-API. That way the lock can be acquired before
> the trace event is invoked and lockdep will see it even if the trace
> event is disabled.
> So there is an idea how to get it to work eventually without disabling
> it in the long term.
>
> Making the register a raw_spinlock_t would solve problem immediately but
> I am a little worried given the increased latency in a quick test:
> https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
>
> also, this one single hardware but the upper limit atomic-polls is high.
>
>>> 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
>>
>> Not sure about why cond_resched was put between irq_work_queue and
>> irq_work_sync - would it not be like-for-like change to have the two
>> together?
>
> maybe it loops for a while and an additional scheduling would be nice.
>
>> Commit message makes me think _queue already starts the handler on
>> x86 at least.
>
> Yes, irq_work_queue() triggers the IRQ right away on x86,
> irq_work_sync() would wait for it to happen in case it did not happen.
> On architectures which don't provide an IRQ-work interrupt, it is
> delayed to the HZ tick timer interrupt. So this serves also as an
> example in case someone want to copy the code ;)
My question wasn't why is there a need_resched() in there, but why is
the patch:
+ irq_work_queue(&b->irq_work);
cond_resched();
+ irq_work_sync(&b->irq_work);
And not:
+ irq_work_queue(&b->irq_work);
+ irq_work_sync(&b->irq_work);
cond_resched();
To preserve like for like, if my understanding of the commit message was
correct.
>
>>> 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
>>
>> I think this is okay. The part after the unlock is serialized by the tasklet
>> already.
>>
>> Slight doubt due the comment:
>>
>> local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
>>
>> Makes me want to think about it harder but not now.
>
> Clark reported it and confirmed that the warning is gone on RT and
> everything appears to work ;)
I will need to think about it harder at some point.
> PREEMPT_RT wise there is no synchronisation vs irq_work other than an
> actual lock (in case it is needed).
Okay, marking as todo/later for me. Need to see if enabling breadcrumbs
earlier than it used to be after this patch makes any difference.
>> Another thing to check is if execlists_context_status_change still needs the
>> atomic notifier chain with this change.
>>
>>> 0010-drm-i915-Drop-the-irqs_disabled-check.patch
>>
>> LGTM.
>
> Do you want me to repost that one?
I think it's up to you whether you go one by one, or repost the whole
series or whatever.
>>> Revert-drm-i915-Depend-on-PREEMPT_RT.patch
>>
>> Okay.
>>
>> And finally for this very patch (the thread I am replying to):
>>
>> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Thanks.
Np - and I've pushed this one.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
@ 2022-03-02 11:42 ` Tvrtko Ursulin
0 siblings, 0 replies; 18+ messages in thread
From: Tvrtko Ursulin @ 2022-03-02 11:42 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 01/03/2022 15:13, Sebastian Andrzej Siewior wrote:
> On 2022-03-01 14:27:18 [+0000], Tvrtko Ursulin wrote:
>>> you see:
>>> 0003-drm-i915-Use-preempt_disable-enable_rt-where-recomme.patch
>>> 0004-drm-i915-Don-t-disable-interrupts-on-PREEMPT_RT-duri.patch
>>
>> Two for the display folks.
>>
>>> 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
>>
>> What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
>> solution could be to always force the !ATOMIC path (for the whole
>> _wait_for_atomic macro) on PREEMPT_RT.
>
> Could be one way to handle it. But please don't disable preemption and
> or interrupts for longer period of time as all of it increases the
> overall latency.
I am looking for your guidance of what is the correct thing here.
Main purpose of this macro on the i915 side is to do short waits on GPU
registers changing post write from spin-locked sections. But there were
rare cases when very short waits were needed from unlocked sections,
shorter than 10us (which is AFAIR what usleep_range documents should be
a lower limit). Which is why non-atomic path was added to the macro.
That path uses preempt_disable/enable so it can use local_clock().
All this may, or may not be, compatible with PREEMPT_RT to start with?
Or question phrased differently, how we should implement the <10us waits
from non-atomic sections under PREEMPT_RT?
> Side note: All of these patches is a collection over time. I personally
> have only a single i7-sandybridge with i915 and here I don't really
> enter all the possible paths here. People report, I patch and look
> around and then they are quiet so I assume that it is working.
>
>>> 0006-drm-i915-Disable-tracing-points-on-PREEMPT_RT.patch
>>
>> If the issue is only with certain trace points why disable all?
>
> It is a class and it is easier that way.
>
>>> 0007-drm-i915-skip-DRM_I915_LOW_LEVEL_TRACEPOINTS-with-NO.patch
>>
>> Didn't quite fully understand, why is this not fixable? Especially thinking
>> if the option of not blanket disabling all tracepoints in the previous
>> patch.
>
> The problem is that you can't acquire that lock from within that
> trace-point on PREEMPT_RT. On !RT it is possible but it is also
> problematic because LOCKDEP does not see possible dead locks unless that
> trace-point is enabled.
Oh I meant could the include ordering problem be fixed differently?
"""
[PATCH 07/10] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with
NOTRACE
The order of the header files is important. If this header file is
included after tracepoint.h was included then the NOTRACE here becomes a
nop. Currently this happens for two .c files which use the tracepoitns
behind DRM_I915_LOW_LEVEL_TRACEPOINTS.
"""
Like these two .c files - can order of includes just be changed in them?
>
> I've been talking to Steven (after
> https://lkml.kernel.org/r/20211214115837.6f33a9b2@gandalf.local.home)
> and he wants to come up with something where you can pass a lock as
> argument to the tracing-API. That way the lock can be acquired before
> the trace event is invoked and lockdep will see it even if the trace
> event is disabled.
> So there is an idea how to get it to work eventually without disabling
> it in the long term.
>
> Making the register a raw_spinlock_t would solve problem immediately but
> I am a little worried given the increased latency in a quick test:
> https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
>
> also, this one single hardware but the upper limit atomic-polls is high.
>
>>> 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
>>
>> Not sure about why cond_resched was put between irq_work_queue and
>> irq_work_sync - would it not be like-for-like change to have the two
>> together?
>
> maybe it loops for a while and an additional scheduling would be nice.
>
>> Commit message makes me think _queue already starts the handler on
>> x86 at least.
>
> Yes, irq_work_queue() triggers the IRQ right away on x86,
> irq_work_sync() would wait for it to happen in case it did not happen.
> On architectures which don't provide an IRQ-work interrupt, it is
> delayed to the HZ tick timer interrupt. So this serves also as an
> example in case someone want to copy the code ;)
My question wasn't why is there a need_resched() in there, but why is
the patch:
+ irq_work_queue(&b->irq_work);
cond_resched();
+ irq_work_sync(&b->irq_work);
And not:
+ irq_work_queue(&b->irq_work);
+ irq_work_sync(&b->irq_work);
cond_resched();
To preserve like for like, if my understanding of the commit message was
correct.
>
>>> 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
>>
>> I think this is okay. The part after the unlock is serialized by the tasklet
>> already.
>>
>> Slight doubt due the comment:
>>
>> local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
>>
>> Makes me want to think about it harder but not now.
>
> Clark reported it and confirmed that the warning is gone on RT and
> everything appears to work ;)
I will need to think about it harder at some point.
> PREEMPT_RT wise there is no synchronisation vs irq_work other than an
> actual lock (in case it is needed).
Okay, marking as todo/later for me. Need to see if enabling breadcrumbs
earlier than it used to be after this patch makes any difference.
>> Another thing to check is if execlists_context_status_change still needs the
>> atomic notifier chain with this change.
>>
>>> 0010-drm-i915-Drop-the-irqs_disabled-check.patch
>>
>> LGTM.
>
> Do you want me to repost that one?
I think it's up to you whether you go one by one, or repost the whole
series or whatever.
>>> Revert-drm-i915-Depend-on-PREEMPT_RT.patch
>>
>> Okay.
>>
>> And finally for this very patch (the thread I am replying to):
>>
>> Acked-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>
> Thanks.
Np - and I've pushed this one.
Regards,
Tvrtko
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/i915: Depend on !PREEMPT_RT.
2022-03-02 11:42 ` [Intel-gfx] " Tvrtko Ursulin
@ 2022-03-02 12:32 ` Sebastian Andrzej Siewior
-1 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-03-02 12:32 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 2022-03-02 11:42:35 [+0000], Tvrtko Ursulin wrote:
> > > > 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
> > >
> > > What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
> > > solution could be to always force the !ATOMIC path (for the whole
> > > _wait_for_atomic macro) on PREEMPT_RT.
> >
> > Could be one way to handle it. But please don't disable preemption and
> > or interrupts for longer period of time as all of it increases the
> > overall latency.
>
> I am looking for your guidance of what is the correct thing here.
>
> Main purpose of this macro on the i915 side is to do short waits on GPU
> registers changing post write from spin-locked sections. But there were rare
> cases when very short waits were needed from unlocked sections, shorter than
> 10us (which is AFAIR what usleep_range documents should be a lower limit).
> Which is why non-atomic path was added to the macro. That path uses
> preempt_disable/enable so it can use local_clock().
>
> All this may, or may not be, compatible with PREEMPT_RT to start with?
Your assumption about atomic is not correct and that is why I aim to
ignore for RT. Or maybe alter so it fits.
It is assumed, that in_atomic() is true in an interrupts handler or with
an acquired spinlock_t, right? Both condition keep the context
preemptible so the atomic check triggers. However, both (the force
threaded interrupt handler and the spinlock_t) ensure that the task is
stuck on the CPU.
So maybe your _WAIT_FOR_ATOMIC_CHECK() could point to cant_migrate().
It looks like you try to ensure that local_clock() is from the same CPU.
> Or question phrased differently, how we should implement the <10us waits
> from non-atomic sections under PREEMPT_RT?
I think if you swap check in _WAIT_FOR_ATOMIC_CHECK() it should be good.
After all the remains preemptible during the condition polls so it
should work.
> > The problem is that you can't acquire that lock from within that
> > trace-point on PREEMPT_RT. On !RT it is possible but it is also
> > problematic because LOCKDEP does not see possible dead locks unless that
> > trace-point is enabled.
>
> Oh I meant could the include ordering problem be fixed differently?
>
> """
> [PATCH 07/10] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with
> NOTRACE
>
> The order of the header files is important. If this header file is
> included after tracepoint.h was included then the NOTRACE here becomes a
> nop. Currently this happens for two .c files which use the tracepoitns
> behind DRM_I915_LOW_LEVEL_TRACEPOINTS.
> """
>
> Like these two .c files - can order of includes just be changed in them?
Maybe. Let me check and get back to you.
> > I've been talking to Steven (after
> > https://lkml.kernel.org/r/20211214115837.6f33a9b2@gandalf.local.home)
> > and he wants to come up with something where you can pass a lock as
> > argument to the tracing-API. That way the lock can be acquired before
> > the trace event is invoked and lockdep will see it even if the trace
> > event is disabled.
> > So there is an idea how to get it to work eventually without disabling
> > it in the long term.
> >
> > Making the register a raw_spinlock_t would solve problem immediately but
> > I am a little worried given the increased latency in a quick test:
> > https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
> >
> > also, this one single hardware but the upper limit atomic-polls is high.
> >
> > > > 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
> > >
> > > Not sure about why cond_resched was put between irq_work_queue and
> > > irq_work_sync - would it not be like-for-like change to have the two
> > > together?
> >
> > maybe it loops for a while and an additional scheduling would be nice.
> >
> > > Commit message makes me think _queue already starts the handler on
> > > x86 at least.
> >
> > Yes, irq_work_queue() triggers the IRQ right away on x86,
> > irq_work_sync() would wait for it to happen in case it did not happen.
> > On architectures which don't provide an IRQ-work interrupt, it is
> > delayed to the HZ tick timer interrupt. So this serves also as an
> > example in case someone want to copy the code ;)
>
> My question wasn't why is there a need_resched() in there, but why is the
> patch:
>
> + irq_work_queue(&b->irq_work);
> cond_resched();
> + irq_work_sync(&b->irq_work);
>
> And not:
>
> + irq_work_queue(&b->irq_work);
> + irq_work_sync(&b->irq_work);
> cond_resched();
>
> To preserve like for like, if my understanding of the commit message was
> correct.
No strong need, it can be put as you suggest.
Should someone else schedule &b->irq_work from another CPU then you
could first attempt to cond_resched() and then wait for &b->irq_work's
completion. Assuming that this does not happen (because the irq_work was
previously queued and invoked immediately) irq_work_sync) will just return.
> > > > 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
> > >
> > > I think this is okay. The part after the unlock is serialized by the tasklet
> > > already.
> > >
> > > Slight doubt due the comment:
> > >
> > > local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
> > >
> > > Makes me want to think about it harder but not now.
> >
> > Clark reported it and confirmed that the warning is gone on RT and
> > everything appears to work ;)
>
> I will need to think about it harder at some point.
>
> > PREEMPT_RT wise there is no synchronisation vs irq_work other than an
> > actual lock (in case it is needed).
>
> Okay, marking as todo/later for me. Need to see if enabling breadcrumbs
> earlier than it used to be after this patch makes any difference.
Okay.
> > > Another thing to check is if execlists_context_status_change still needs the
> > > atomic notifier chain with this change.
> > >
> > > > 0010-drm-i915-Drop-the-irqs_disabled-check.patch
> > >
> > > LGTM.
> >
> > Do you want me to repost that one?
>
> I think it's up to you whether you go one by one, or repost the whole series
> or whatever.
If it is up to me then let me repost that one single patch and I have it
out of my queue :) And
0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch without
cond_resched() in the middle.
> Regards,
>
> Tvrtko
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/i915: Depend on !PREEMPT_RT.
@ 2022-03-02 12:32 ` Sebastian Andrzej Siewior
0 siblings, 0 replies; 18+ messages in thread
From: Sebastian Andrzej Siewior @ 2022-03-02 12:32 UTC (permalink / raw)
To: Tvrtko Ursulin
Cc: David Airlie, intel-gfx, Thomas Gleixner, dri-devel, Rodrigo Vivi
On 2022-03-02 11:42:35 [+0000], Tvrtko Ursulin wrote:
> > > > 0005-drm-i915-Don-t-check-for-atomic-context-on-PREEMPT_R.patch
> > >
> > > What do preempt_disable/enable do on PREEMPT_RT? Thinking if instead the
> > > solution could be to always force the !ATOMIC path (for the whole
> > > _wait_for_atomic macro) on PREEMPT_RT.
> >
> > Could be one way to handle it. But please don't disable preemption and
> > or interrupts for longer period of time as all of it increases the
> > overall latency.
>
> I am looking for your guidance of what is the correct thing here.
>
> Main purpose of this macro on the i915 side is to do short waits on GPU
> registers changing post write from spin-locked sections. But there were rare
> cases when very short waits were needed from unlocked sections, shorter than
> 10us (which is AFAIR what usleep_range documents should be a lower limit).
> Which is why non-atomic path was added to the macro. That path uses
> preempt_disable/enable so it can use local_clock().
>
> All this may, or may not be, compatible with PREEMPT_RT to start with?
Your assumption about atomic is not correct and that is why I aim to
ignore for RT. Or maybe alter so it fits.
It is assumed, that in_atomic() is true in an interrupts handler or with
an acquired spinlock_t, right? Both condition keep the context
preemptible so the atomic check triggers. However, both (the force
threaded interrupt handler and the spinlock_t) ensure that the task is
stuck on the CPU.
So maybe your _WAIT_FOR_ATOMIC_CHECK() could point to cant_migrate().
It looks like you try to ensure that local_clock() is from the same CPU.
> Or question phrased differently, how we should implement the <10us waits
> from non-atomic sections under PREEMPT_RT?
I think if you swap check in _WAIT_FOR_ATOMIC_CHECK() it should be good.
After all the remains preemptible during the condition polls so it
should work.
> > The problem is that you can't acquire that lock from within that
> > trace-point on PREEMPT_RT. On !RT it is possible but it is also
> > problematic because LOCKDEP does not see possible dead locks unless that
> > trace-point is enabled.
>
> Oh I meant could the include ordering problem be fixed differently?
>
> """
> [PATCH 07/10] drm/i915: skip DRM_I915_LOW_LEVEL_TRACEPOINTS with
> NOTRACE
>
> The order of the header files is important. If this header file is
> included after tracepoint.h was included then the NOTRACE here becomes a
> nop. Currently this happens for two .c files which use the tracepoitns
> behind DRM_I915_LOW_LEVEL_TRACEPOINTS.
> """
>
> Like these two .c files - can order of includes just be changed in them?
Maybe. Let me check and get back to you.
> > I've been talking to Steven (after
> > https://lkml.kernel.org/r/20211214115837.6f33a9b2@gandalf.local.home)
> > and he wants to come up with something where you can pass a lock as
> > argument to the tracing-API. That way the lock can be acquired before
> > the trace event is invoked and lockdep will see it even if the trace
> > event is disabled.
> > So there is an idea how to get it to work eventually without disabling
> > it in the long term.
> >
> > Making the register a raw_spinlock_t would solve problem immediately but
> > I am a little worried given the increased latency in a quick test:
> > https://lore.kernel.org/all/20211006164628.s2mtsdd2jdbfyf7g@linutronix.de/
> >
> > also, this one single hardware but the upper limit atomic-polls is high.
> >
> > > > 0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch
> > >
> > > Not sure about why cond_resched was put between irq_work_queue and
> > > irq_work_sync - would it not be like-for-like change to have the two
> > > together?
> >
> > maybe it loops for a while and an additional scheduling would be nice.
> >
> > > Commit message makes me think _queue already starts the handler on
> > > x86 at least.
> >
> > Yes, irq_work_queue() triggers the IRQ right away on x86,
> > irq_work_sync() would wait for it to happen in case it did not happen.
> > On architectures which don't provide an IRQ-work interrupt, it is
> > delayed to the HZ tick timer interrupt. So this serves also as an
> > example in case someone want to copy the code ;)
>
> My question wasn't why is there a need_resched() in there, but why is the
> patch:
>
> + irq_work_queue(&b->irq_work);
> cond_resched();
> + irq_work_sync(&b->irq_work);
>
> And not:
>
> + irq_work_queue(&b->irq_work);
> + irq_work_sync(&b->irq_work);
> cond_resched();
>
> To preserve like for like, if my understanding of the commit message was
> correct.
No strong need, it can be put as you suggest.
Should someone else schedule &b->irq_work from another CPU then you
could first attempt to cond_resched() and then wait for &b->irq_work's
completion. Assuming that this does not happen (because the irq_work was
previously queued and invoked immediately) irq_work_sync) will just return.
> > > > 0009-drm-i915-gt-Use-spin_lock_irq-instead-of-local_irq_d.patch
> > >
> > > I think this is okay. The part after the unlock is serialized by the tasklet
> > > already.
> > >
> > > Slight doubt due the comment:
> > >
> > > local_irq_enable(); /* flush irq_work (e.g. breadcrumb enabling) */
> > >
> > > Makes me want to think about it harder but not now.
> >
> > Clark reported it and confirmed that the warning is gone on RT and
> > everything appears to work ;)
>
> I will need to think about it harder at some point.
>
> > PREEMPT_RT wise there is no synchronisation vs irq_work other than an
> > actual lock (in case it is needed).
>
> Okay, marking as todo/later for me. Need to see if enabling breadcrumbs
> earlier than it used to be after this patch makes any difference.
Okay.
> > > Another thing to check is if execlists_context_status_change still needs the
> > > atomic notifier chain with this change.
> > >
> > > > 0010-drm-i915-Drop-the-irqs_disabled-check.patch
> > >
> > > LGTM.
> >
> > Do you want me to repost that one?
>
> I think it's up to you whether you go one by one, or repost the whole series
> or whatever.
If it is up to me then let me repost that one single patch and I have it
out of my queue :) And
0008-drm-i915-gt-Queue-and-wait-for-the-irq_work-item.patch without
cond_resched() in the middle.
> Regards,
>
> Tvrtko
Sebastian
^ permalink raw reply [flat|nested] 18+ messages in thread