[PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chuansheng Liu]

Reference:
https://bugs.freedesktop.org/show_bug.cgi?id=112126

The issue we hit is the GPU keeps very high load after running
the subtest min-max-config-loaded.

Some background of the issue:
Currently the rps is not fully enabled yet on TGL, and running
the subtest min-max-config-loaded will hit below assertion:
==
(i915_pm_rps:1261) CRITICAL: Test assertion failure function loaded_check, file ../tests/i915/i915_pm_rps.c:505:
(i915_pm_rps:1261) CRITICAL: Failed assertion: freqs[MAX] <= freqs[CUR]
(i915_pm_rps:1261) CRITICAL: Last errno: 2, No such file or directory
==

with igt stress test, we find the GT keeps busy after running
this subtest, it is due to the igt_spin_end() is not called
randomly.

The root cause analysis is:
When the main process i915_pm_rps for running the subtest
min-max-config-loaded hits the assertion, the main process will
try to send signal SIGTERM to the child process loader_helper
which is created by main process for starting GT load, then the
main process itself will exit.

The SIGTERM handler for loader_helper is the default one, which
will cause the loader_helper exits directly. That is unsafe, we
always expect the igt_spin_end() is called before loader_helper
process exits, which is used to stop the load of GT.

Furthermore, in normal scenario, before main process exits,
it will send SIGUSR1 to child process for stopping GT loading
in safe way.

So here we install the proper handler for signal SIGTERM in the
similar way. Without this patch, the GT may keep busy after
running this subtest. Enabling rps should be tracked on the
other side.

Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
---
 tests/i915/i915_pm_rps.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
index ef627c0b..8c71c1a1 100644
--- a/tests/i915/i915_pm_rps.c
+++ b/tests/i915/i915_pm_rps.c
@@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
 
 		signal(SIGUSR1, load_helper_signal_handler);
 		signal(SIGUSR2, load_helper_signal_handler);
+		signal(SIGTERM, load_helper_signal_handler);
 
 		igt_debug("Applying %s load...\n", lh.load ? "high" : "low");
 
-- 
2.17.1

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

[Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chuansheng Liu]

Reference:
https://bugs.freedesktop.org/show_bug.cgi?id=112126

The issue we hit is the GPU keeps very high load after running
the subtest min-max-config-loaded.

Some background of the issue:
Currently the rps is not fully enabled yet on TGL, and running
the subtest min-max-config-loaded will hit below assertion:
==
(i915_pm_rps:1261) CRITICAL: Test assertion failure function loaded_check, file ../tests/i915/i915_pm_rps.c:505:
(i915_pm_rps:1261) CRITICAL: Failed assertion: freqs[MAX] <= freqs[CUR]
(i915_pm_rps:1261) CRITICAL: Last errno: 2, No such file or directory
==

with igt stress test, we find the GT keeps busy after running
this subtest, it is due to the igt_spin_end() is not called
randomly.

The root cause analysis is:
When the main process i915_pm_rps for running the subtest
min-max-config-loaded hits the assertion, the main process will
try to send signal SIGTERM to the child process loader_helper
which is created by main process for starting GT load, then the
main process itself will exit.

The SIGTERM handler for loader_helper is the default one, which
will cause the loader_helper exits directly. That is unsafe, we
always expect the igt_spin_end() is called before loader_helper
process exits, which is used to stop the load of GT.

Furthermore, in normal scenario, before main process exits,
it will send SIGUSR1 to child process for stopping GT loading
in safe way.

So here we install the proper handler for signal SIGTERM in the
similar way. Without this patch, the GT may keep busy after
running this subtest. Enabling rps should be tracked on the
other side.

Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
---
 tests/i915/i915_pm_rps.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
index ef627c0b..8c71c1a1 100644
--- a/tests/i915/i915_pm_rps.c
+++ b/tests/i915/i915_pm_rps.c
@@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
 
 		signal(SIGUSR1, load_helper_signal_handler);
 		signal(SIGUSR2, load_helper_signal_handler);
+		signal(SIGTERM, load_helper_signal_handler);
 
 		igt_debug("Applying %s load...\n", lh.load ? "high" : "low");
 
-- 
2.17.1

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

[igt-dev] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chuansheng Liu]

Reference:
https://bugs.freedesktop.org/show_bug.cgi?id=112126

The issue we hit is the GPU keeps very high load after running
the subtest min-max-config-loaded.

Some background of the issue:
Currently the rps is not fully enabled yet on TGL, and running
the subtest min-max-config-loaded will hit below assertion:
==
(i915_pm_rps:1261) CRITICAL: Test assertion failure function loaded_check, file ../tests/i915/i915_pm_rps.c:505:
(i915_pm_rps:1261) CRITICAL: Failed assertion: freqs[MAX] <= freqs[CUR]
(i915_pm_rps:1261) CRITICAL: Last errno: 2, No such file or directory
==

with igt stress test, we find the GT keeps busy after running
this subtest, it is due to the igt_spin_end() is not called
randomly.

The root cause analysis is:
When the main process i915_pm_rps for running the subtest
min-max-config-loaded hits the assertion, the main process will
try to send signal SIGTERM to the child process loader_helper
which is created by main process for starting GT load, then the
main process itself will exit.

The SIGTERM handler for loader_helper is the default one, which
will cause the loader_helper exits directly. That is unsafe, we
always expect the igt_spin_end() is called before loader_helper
process exits, which is used to stop the load of GT.

Furthermore, in normal scenario, before main process exits,
it will send SIGUSR1 to child process for stopping GT loading
in safe way.

So here we install the proper handler for signal SIGTERM in the
similar way. Without this patch, the GT may keep busy after
running this subtest. Enabling rps should be tracked on the
other side.

Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
---
 tests/i915/i915_pm_rps.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
index ef627c0b..8c71c1a1 100644
--- a/tests/i915/i915_pm_rps.c
+++ b/tests/i915/i915_pm_rps.c
@@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
 
 		signal(SIGUSR1, load_helper_signal_handler);
 		signal(SIGUSR2, load_helper_signal_handler);
+		signal(SIGTERM, load_helper_signal_handler);
 
 		igt_debug("Applying %s load...\n", lh.load ? "high" : "low");
 
-- 
2.17.1

_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for i915/pm_rps: install SIGTERM handler for load_helper process

[Patchwork]

== Series Details ==

Series: i915/pm_rps: install SIGTERM handler for load_helper process
URL   : https://patchwork.freedesktop.org/series/69716/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7380 -> IGTPW_3732
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/index.html

Known issues
------------

  Here are the changes found in IGTPW_3732 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@kms_flip@basic-flip-vs-dpms:
    - fi-skl-6770hq:      [PASS][1] -> [SKIP][2] ([fdo#109271]) +26 similar issues
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-dpms.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/fi-skl-6770hq/igt@kms_flip@basic-flip-vs-dpms.html

  
#### Possible fixes ####

  * igt@i915_module_load@reload-with-fault-injection:
    - fi-bsw-nick:        [INCOMPLETE][3] ([fdo#105876]) -> [PASS][4]
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/fi-bsw-nick/igt@i915_module_load@reload-with-fault-injection.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/fi-bsw-nick/igt@i915_module_load@reload-with-fault-injection.html

  * igt@i915_pm_rpm@module-reload:
    - fi-skl-6770hq:      [FAIL][5] ([fdo#108511]) -> [PASS][6]
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/fi-skl-6770hq/igt@i915_pm_rpm@module-reload.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876
  [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
  [fdo#112298]: https://bugs.freedesktop.org/show_bug.cgi?id=112298


Participating hosts (49 -> 44)
------------------------------

  Additional (1): fi-hsw-4770r 
  Missing    (6): fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


Build changes
-------------

  * CI: CI-20190529 -> None
  * IGT: IGT_5295 -> IGTPW_3732

  CI-20190529: 20190529
  CI_DRM_7380: 7b0a3189ead776ce02426186e8d63cff190a453e @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_3732: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/index.html
  IGT_5295: 9211e4794e40135d797e6d056d6d8d40076acb92 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chris Wilson]

Quoting Chuansheng Liu (2019-11-20 06:29:12)
> Reference:
> https://bugs.freedesktop.org/show_bug.cgi?id=112126
> 
> The issue we hit is the GPU keeps very high load after running
> the subtest min-max-config-loaded.
> 
> Some background of the issue:
> Currently the rps is not fully enabled yet on TGL, and running
> the subtest min-max-config-loaded will hit below assertion:
> ==
> (i915_pm_rps:1261) CRITICAL: Test assertion failure function loaded_check, file ../tests/i915/i915_pm_rps.c:505:
> (i915_pm_rps:1261) CRITICAL: Failed assertion: freqs[MAX] <= freqs[CUR]
> (i915_pm_rps:1261) CRITICAL: Last errno: 2, No such file or directory
> ==
> 
> with igt stress test, we find the GT keeps busy after running
> this subtest, it is due to the igt_spin_end() is not called
> randomly.
> 
> The root cause analysis is:
> When the main process i915_pm_rps for running the subtest
> min-max-config-loaded hits the assertion, the main process will
> try to send signal SIGTERM to the child process loader_helper
> which is created by main process for starting GT load, then the
> main process itself will exit.
> 
> The SIGTERM handler for loader_helper is the default one, which
> will cause the loader_helper exits directly. That is unsafe, we
> always expect the igt_spin_end() is called before loader_helper
> process exits, which is used to stop the load of GT.
> 
> Furthermore, in normal scenario, before main process exits,
> it will send SIGUSR1 to child process for stopping GT loading
> in safe way.
> 
> So here we install the proper handler for signal SIGTERM in the
> similar way. Without this patch, the GT may keep busy after
> running this subtest. Enabling rps should be tracked on the
> other side.
> 
> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> ---
>  tests/i915/i915_pm_rps.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> index ef627c0b..8c71c1a1 100644
> --- a/tests/i915/i915_pm_rps.c
> +++ b/tests/i915/i915_pm_rps.c
> @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
>  
>                 signal(SIGUSR1, load_helper_signal_handler);
>                 signal(SIGUSR2, load_helper_signal_handler);
> +               signal(SIGTERM, load_helper_signal_handler);

I don't see any behaviour changes to igt to cause it to send SIGTERM on
exit_subtest.

But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
intentions.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chris Wilson]

Quoting Chuansheng Liu (2019-11-20 06:29:12)
> Reference:
> https://bugs.freedesktop.org/show_bug.cgi?id=112126
> 
> The issue we hit is the GPU keeps very high load after running
> the subtest min-max-config-loaded.
> 
> Some background of the issue:
> Currently the rps is not fully enabled yet on TGL, and running
> the subtest min-max-config-loaded will hit below assertion:
> ==
> (i915_pm_rps:1261) CRITICAL: Test assertion failure function loaded_check, file ../tests/i915/i915_pm_rps.c:505:
> (i915_pm_rps:1261) CRITICAL: Failed assertion: freqs[MAX] <= freqs[CUR]
> (i915_pm_rps:1261) CRITICAL: Last errno: 2, No such file or directory
> ==
> 
> with igt stress test, we find the GT keeps busy after running
> this subtest, it is due to the igt_spin_end() is not called
> randomly.
> 
> The root cause analysis is:
> When the main process i915_pm_rps for running the subtest
> min-max-config-loaded hits the assertion, the main process will
> try to send signal SIGTERM to the child process loader_helper
> which is created by main process for starting GT load, then the
> main process itself will exit.
> 
> The SIGTERM handler for loader_helper is the default one, which
> will cause the loader_helper exits directly. That is unsafe, we
> always expect the igt_spin_end() is called before loader_helper
> process exits, which is used to stop the load of GT.
> 
> Furthermore, in normal scenario, before main process exits,
> it will send SIGUSR1 to child process for stopping GT loading
> in safe way.
> 
> So here we install the proper handler for signal SIGTERM in the
> similar way. Without this patch, the GT may keep busy after
> running this subtest. Enabling rps should be tracked on the
> other side.
> 
> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> ---
>  tests/i915/i915_pm_rps.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> index ef627c0b..8c71c1a1 100644
> --- a/tests/i915/i915_pm_rps.c
> +++ b/tests/i915/i915_pm_rps.c
> @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
>  
>                 signal(SIGUSR1, load_helper_signal_handler);
>                 signal(SIGUSR2, load_helper_signal_handler);
> +               signal(SIGTERM, load_helper_signal_handler);

I don't see any behaviour changes to igt to cause it to send SIGTERM on
exit_subtest.

But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
intentions.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chris Wilson]

Quoting Chuansheng Liu (2019-11-20 06:29:12)
> Reference:
> https://bugs.freedesktop.org/show_bug.cgi?id=112126
> 
> The issue we hit is the GPU keeps very high load after running
> the subtest min-max-config-loaded.
> 
> Some background of the issue:
> Currently the rps is not fully enabled yet on TGL, and running
> the subtest min-max-config-loaded will hit below assertion:
> ==
> (i915_pm_rps:1261) CRITICAL: Test assertion failure function loaded_check, file ../tests/i915/i915_pm_rps.c:505:
> (i915_pm_rps:1261) CRITICAL: Failed assertion: freqs[MAX] <= freqs[CUR]
> (i915_pm_rps:1261) CRITICAL: Last errno: 2, No such file or directory
> ==
> 
> with igt stress test, we find the GT keeps busy after running
> this subtest, it is due to the igt_spin_end() is not called
> randomly.
> 
> The root cause analysis is:
> When the main process i915_pm_rps for running the subtest
> min-max-config-loaded hits the assertion, the main process will
> try to send signal SIGTERM to the child process loader_helper
> which is created by main process for starting GT load, then the
> main process itself will exit.
> 
> The SIGTERM handler for loader_helper is the default one, which
> will cause the loader_helper exits directly. That is unsafe, we
> always expect the igt_spin_end() is called before loader_helper
> process exits, which is used to stop the load of GT.
> 
> Furthermore, in normal scenario, before main process exits,
> it will send SIGUSR1 to child process for stopping GT loading
> in safe way.
> 
> So here we install the proper handler for signal SIGTERM in the
> similar way. Without this patch, the GT may keep busy after
> running this subtest. Enabling rps should be tracked on the
> other side.
> 
> Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> ---
>  tests/i915/i915_pm_rps.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> index ef627c0b..8c71c1a1 100644
> --- a/tests/i915/i915_pm_rps.c
> +++ b/tests/i915/i915_pm_rps.c
> @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
>  
>                 signal(SIGUSR1, load_helper_signal_handler);
>                 signal(SIGUSR2, load_helper_signal_handler);
> +               signal(SIGTERM, load_helper_signal_handler);

I don't see any behaviour changes to igt to cause it to send SIGTERM on
exit_subtest.

But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
intentions.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.IGT: success for i915/pm_rps: install SIGTERM handler for load_helper process

[Patchwork]

== Series Details ==

Series: i915/pm_rps: install SIGTERM handler for load_helper process
URL   : https://patchwork.freedesktop.org/series/69716/
State : success

== Summary ==

CI Bug Log - changes from CI_DRM_7380_full -> IGTPW_3732_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/index.html

Known issues
------------

  Here are the changes found in IGTPW_3732_full that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@gem_ctx_create@basic-files:
    - shard-iclb:         [PASS][1] -> [DMESG-WARN][2] ([fdo#112348])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb3/igt@gem_ctx_create@basic-files.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb7/igt@gem_ctx_create@basic-files.html

  * igt@gem_ctx_isolation@vcs1-dirty-create:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +3 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb1/igt@gem_ctx_isolation@vcs1-dirty-create.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb8/igt@gem_ctx_isolation@vcs1-dirty-create.html

  * igt@gem_ctx_shared@q-smoketest-all:
    - shard-tglb:         [PASS][5] -> [INCOMPLETE][6] ([fdo#111735])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb8/igt@gem_ctx_shared@q-smoketest-all.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb6/igt@gem_ctx_shared@q-smoketest-all.html

  * igt@gem_eio@in-flight-suspend:
    - shard-kbl:          [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +6 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-kbl7/igt@gem_eio@in-flight-suspend.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-kbl6/igt@gem_eio@in-flight-suspend.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [PASS][9] -> [SKIP][10] ([fdo#110854])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb2/igt@gem_exec_balancer@smoke.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb5/igt@gem_exec_balancer@smoke.html

  * igt@gem_exec_schedule@wide-bsd:
    - shard-iclb:         [PASS][11] -> [SKIP][12] ([fdo#112146]) +1 similar issue
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb6/igt@gem_exec_schedule@wide-bsd.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb2/igt@gem_exec_schedule@wide-bsd.html

  * igt@gem_exec_store@cachelines-vcs1:
    - shard-iclb:         [PASS][13] -> [SKIP][14] ([fdo#112080]) +10 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb4/igt@gem_exec_store@cachelines-vcs1.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb8/igt@gem_exec_store@cachelines-vcs1.html

  * igt@gem_exec_suspend@basic-s0:
    - shard-tglb:         [PASS][15] -> [INCOMPLETE][16] ([fdo#111832]) +2 similar issues
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb4/igt@gem_exec_suspend@basic-s0.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb7/igt@gem_exec_suspend@basic-s0.html

  * igt@gem_userptr_blits@sync-unmap-cycles:
    - shard-snb:          [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) +2 similar issues
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-snb7/igt@gem_userptr_blits@sync-unmap-cycles.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-snb6/igt@gem_userptr_blits@sync-unmap-cycles.html
    - shard-hsw:          [PASS][19] -> [DMESG-WARN][20] ([fdo#111870]) +3 similar issues
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-hsw2/igt@gem_userptr_blits@sync-unmap-cycles.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-hsw1/igt@gem_userptr_blits@sync-unmap-cycles.html

  * igt@gem_workarounds@suspend-resume-context:
    - shard-tglb:         [PASS][21] -> [INCOMPLETE][22] ([fdo#111832] / [fdo#111850])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb3/igt@gem_workarounds@suspend-resume-context.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb5/igt@gem_workarounds@suspend-resume-context.html

  * igt@i915_pm_rpm@system-suspend-modeset:
    - shard-iclb:         [PASS][23] -> [INCOMPLETE][24] ([fdo#107713] / [fdo#108840])
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb8/igt@i915_pm_rpm@system-suspend-modeset.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb3/igt@i915_pm_rpm@system-suspend-modeset.html

  * igt@i915_selftest@live_hangcheck:
    - shard-hsw:          [PASS][25] -> [DMESG-FAIL][26] ([fdo#111991])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-hsw2/igt@i915_selftest@live_hangcheck.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-hsw6/igt@i915_selftest@live_hangcheck.html

  * igt@i915_suspend@forcewake:
    - shard-kbl:          [PASS][27] -> [INCOMPLETE][28] ([fdo#103665] / [fdo#112219])
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-kbl4/igt@i915_suspend@forcewake.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-kbl3/igt@i915_suspend@forcewake.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
    - shard-hsw:          [PASS][29] -> [FAIL][30] ([fdo#105767])
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-hsw1/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-hsw4/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html

  * igt@kms_flip@flip-vs-suspend-interruptible:
    - shard-apl:          [PASS][31] -> [DMESG-WARN][32] ([fdo#108566]) +1 similar issue
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-apl1/igt@kms_flip@flip-vs-suspend-interruptible.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-apl4/igt@kms_flip@flip-vs-suspend-interruptible.html
    - shard-hsw:          [PASS][33] -> [INCOMPLETE][34] ([fdo#103540])
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-hsw1/igt@kms_flip@flip-vs-suspend-interruptible.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-hsw1/igt@kms_flip@flip-vs-suspend-interruptible.html

  * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
    - shard-iclb:         [PASS][35] -> [FAIL][36] ([fdo#103167]) +4 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb8/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render.html

  * igt@kms_frontbuffer_tracking@fbcpsr-tilingchange:
    - shard-tglb:         [PASS][37] -> [FAIL][38] ([fdo#103167])
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb7/igt@kms_frontbuffer_tracking@fbcpsr-tilingchange.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb7/igt@kms_frontbuffer_tracking@fbcpsr-tilingchange.html

  * igt@kms_plane@pixel-format-pipe-c-planes:
    - shard-tglb:         [PASS][39] -> [FAIL][40] ([fdo#112275])
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb2/igt@kms_plane@pixel-format-pipe-c-planes.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb3/igt@kms_plane@pixel-format-pipe-c-planes.html
    - shard-iclb:         [PASS][41] -> [FAIL][42] ([fdo#112213])
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb2/igt@kms_plane@pixel-format-pipe-c-planes.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb1/igt@kms_plane@pixel-format-pipe-c-planes.html

  * igt@kms_plane@plane-position-covered-pipe-a-planes:
    - shard-apl:          [PASS][43] -> [FAIL][44] ([fdo#110038])
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-apl6/igt@kms_plane@plane-position-covered-pipe-a-planes.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-apl3/igt@kms_plane@plane-position-covered-pipe-a-planes.html
    - shard-kbl:          [PASS][45] -> [FAIL][46] ([fdo#110038])
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-kbl7/igt@kms_plane@plane-position-covered-pipe-a-planes.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-kbl1/igt@kms_plane@plane-position-covered-pipe-a-planes.html

  * igt@kms_psr@psr2_sprite_blt:
    - shard-iclb:         [PASS][47] -> [SKIP][48] ([fdo#109441])
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb2/igt@kms_psr@psr2_sprite_blt.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb6/igt@kms_psr@psr2_sprite_blt.html

  * igt@kms_setmode@basic:
    - shard-apl:          [PASS][49] -> [FAIL][50] ([fdo#99912])
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-apl7/igt@kms_setmode@basic.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-apl7/igt@kms_setmode@basic.html

  * igt@kms_universal_plane@universal-plane-pipe-c-functional:
    - shard-kbl:          [PASS][51] -> [FAIL][52] ([fdo#111134])
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-kbl6/igt@kms_universal_plane@universal-plane-pipe-c-functional.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-kbl2/igt@kms_universal_plane@universal-plane-pipe-c-functional.html

  * igt@kms_vblank@pipe-d-ts-continuation-suspend:
    - shard-tglb:         [PASS][53] -> [INCOMPLETE][54] ([fdo#111850])
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb9/igt@kms_vblank@pipe-d-ts-continuation-suspend.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb5/igt@kms_vblank@pipe-d-ts-continuation-suspend.html

  * igt@prime_busy@hang-bsd2:
    - shard-iclb:         [PASS][55] -> [SKIP][56] ([fdo#109276]) +17 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb4/igt@prime_busy@hang-bsd2.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb6/igt@prime_busy@hang-bsd2.html

  
#### Possible fixes ####

  * igt@gem_ctx_exec@basic-invalid-context-vcs1:
    - shard-iclb:         [SKIP][57] ([fdo#112080]) -> [PASS][58] +8 similar issues
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb6/igt@gem_ctx_exec@basic-invalid-context-vcs1.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb2/igt@gem_ctx_exec@basic-invalid-context-vcs1.html

  * igt@gem_ctx_persistence@vcs1-queued:
    - shard-iclb:         [SKIP][59] ([fdo#109276] / [fdo#112080]) -> [PASS][60] +1 similar issue
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb8/igt@gem_ctx_persistence@vcs1-queued.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb2/igt@gem_ctx_persistence@vcs1-queued.html

  * igt@gem_eio@suspend:
    - shard-tglb:         [INCOMPLETE][61] ([fdo#111850]) -> [PASS][62] +1 similar issue
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb3/igt@gem_eio@suspend.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb6/igt@gem_eio@suspend.html

  * igt@gem_exec_schedule@preemptive-hang-bsd:
    - shard-iclb:         [SKIP][63] ([fdo#112146]) -> [PASS][64] +3 similar issues
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb2/igt@gem_exec_schedule@preemptive-hang-bsd.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb3/igt@gem_exec_schedule@preemptive-hang-bsd.html

  * igt@gem_softpin@evict-active-interruptible:
    - shard-tglb:         [TIMEOUT][65] ([fdo#112126]) -> [PASS][66]
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb1/igt@gem_softpin@evict-active-interruptible.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb4/igt@gem_softpin@evict-active-interruptible.html

  * igt@gem_userptr_blits@map-fixed-invalidate-busy:
    - shard-snb:          [DMESG-WARN][67] ([fdo#111870]) -> [PASS][68] +1 similar issue
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-snb7/igt@gem_userptr_blits@map-fixed-invalidate-busy.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-snb4/igt@gem_userptr_blits@map-fixed-invalidate-busy.html
    - shard-hsw:          [DMESG-WARN][69] ([fdo#111870]) -> [PASS][70] +1 similar issue
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-hsw4/igt@gem_userptr_blits@map-fixed-invalidate-busy.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-hsw6/igt@gem_userptr_blits@map-fixed-invalidate-busy.html

  * igt@gem_workarounds@suspend-resume:
    - shard-kbl:          [DMESG-WARN][71] ([fdo#108566]) -> [PASS][72] +1 similar issue
   [71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-kbl7/igt@gem_workarounds@suspend-resume.html
   [72]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-kbl2/igt@gem_workarounds@suspend-resume.html

  * igt@i915_suspend@debugfs-reader:
    - shard-apl:          [DMESG-WARN][73] ([fdo#108566]) -> [PASS][74] +2 similar issues
   [73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-apl1/igt@i915_suspend@debugfs-reader.html
   [74]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-apl6/igt@i915_suspend@debugfs-reader.html

  * igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen:
    - shard-apl:          [FAIL][75] ([fdo#103232]) -> [PASS][76]
   [75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-apl8/igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen.html
   [76]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-apl7/igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen.html
    - shard-kbl:          [FAIL][77] ([fdo#103232]) -> [PASS][78]
   [77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen.html
   [78]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-kbl2/igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen.html

  * igt@kms_cursor_edge_walk@pipe-a-128x128-right-edge:
    - shard-tglb:         [INCOMPLETE][79] -> [PASS][80]
   [79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb1/igt@kms_cursor_edge_walk@pipe-a-128x128-right-edge.html
   [80]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb4/igt@kms_cursor_edge_walk@pipe-a-128x128-right-edge.html

  * igt@kms_flip@2x-flip-vs-suspend:
    - shard-hsw:          [INCOMPLETE][81] ([fdo#103540]) -> [PASS][82]
   [81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-hsw8/igt@kms_flip@2x-flip-vs-suspend.html
   [82]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-hsw6/igt@kms_flip@2x-flip-vs-suspend.html

  * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt:
    - shard-iclb:         [FAIL][83] ([fdo#103167]) -> [PASS][84] +1 similar issue
   [83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb4/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt.html
   [84]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb1/igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-blt.html

  * igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-wc:
    - shard-tglb:         [TIMEOUT][85] ([fdo#112168]) -> [PASS][86]
   [85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-wc.html
   [86]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb8/igt@kms_frontbuffer_tracking@fbcpsr-1p-offscren-pri-indfb-draw-mmap-wc.html

  * igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
    - shard-tglb:         [FAIL][87] ([fdo#112275]) -> [PASS][88]
   [87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb8/igt@kms_plane@pixel-format-pipe-a-planes-source-clamping.html
   [88]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb6/igt@kms_plane@pixel-format-pipe-a-planes-source-clamping.html
    - shard-iclb:         [FAIL][89] ([fdo#112213]) -> [PASS][90]
   [89]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb6/igt@kms_plane@pixel-format-pipe-a-planes-source-clamping.html
   [90]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb8/igt@kms_plane@pixel-format-pipe-a-planes-source-clamping.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-iclb:         [FAIL][91] ([fdo#103166]) -> [PASS][92]
   [91]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb7/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [92]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb1/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_sprite_plane_move:
    - shard-iclb:         [SKIP][93] ([fdo#109441]) -> [PASS][94] +2 similar issues
   [93]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb3/igt@kms_psr@psr2_sprite_plane_move.html
   [94]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb2/igt@kms_psr@psr2_sprite_plane_move.html

  * igt@kms_setmode@basic:
    - shard-kbl:          [FAIL][95] ([fdo#99912]) -> [PASS][96]
   [95]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-kbl7/igt@kms_setmode@basic.html
   [96]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-kbl7/igt@kms_setmode@basic.html

  * igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend:
    - shard-tglb:         [INCOMPLETE][97] ([fdo#111832] / [fdo#111850]) -> [PASS][98] +2 similar issues
   [97]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb4/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html
   [98]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb5/igt@kms_vblank@pipe-a-ts-continuation-dpms-suspend.html

  * igt@prime_vgem@fence-wait-bsd2:
    - shard-iclb:         [SKIP][99] ([fdo#109276]) -> [PASS][100] +16 similar issues
   [99]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb3/igt@prime_vgem@fence-wait-bsd2.html
   [100]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb2/igt@prime_vgem@fence-wait-bsd2.html

  
#### Warnings ####

  * igt@gem_ctx_isolation@vcs1-nonpriv:
    - shard-iclb:         [FAIL][101] ([fdo#111329]) -> [SKIP][102] ([fdo#109276] / [fdo#112080])
   [101]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html
   [102]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb3/igt@gem_ctx_isolation@vcs1-nonpriv.html

  * igt@gem_ctx_isolation@vcs1-nonpriv-switch:
    - shard-iclb:         [SKIP][103] ([fdo#109276] / [fdo#112080]) -> [FAIL][104] ([fdo#111329])
   [103]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-iclb5/igt@gem_ctx_isolation@vcs1-nonpriv-switch.html
   [104]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-iclb4/igt@gem_ctx_isolation@vcs1-nonpriv-switch.html

  * igt@gem_ctx_isolation@vcs2-nonpriv-switch:
    - shard-tglb:         [SKIP][105] ([fdo#112080]) -> [SKIP][106] ([fdo#111912] / [fdo#112080])
   [105]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb9/igt@gem_ctx_isolation@vcs2-nonpriv-switch.html
   [106]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb8/igt@gem_ctx_isolation@vcs2-nonpriv-switch.html

  * igt@gem_exec_schedule@deep-bsd1:
    - shard-tglb:         [FAIL][107] ([fdo#111646]) -> [INCOMPLETE][108] ([fdo#111671]) +1 similar issue
   [107]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7380/shard-tglb9/igt@gem_exec_schedule@deep-bsd1.html
   [108]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/shard-tglb7/igt@gem_exec_schedule@deep-bsd1.html

  
  {name}: This element is suppressed. This means it is ignored when computing
          the status of the difference (SUCCESS, WARNING, or FAILURE).

  [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
  [fdo#103167]: https://bugs.f

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3732/index.html
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Liu, Chuansheng]

Thanks for reviewing the patch, please see below comments.

> > So here we install the proper handler for signal SIGTERM in the
> > similar way. Without this patch, the GT may keep busy after
> > running this subtest. Enabling rps should be tracked on the
> > other side.
> >
> > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > ---
> >  tests/i915/i915_pm_rps.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > index ef627c0b..8c71c1a1 100644
> > --- a/tests/i915/i915_pm_rps.c
> > +++ b/tests/i915/i915_pm_rps.c
> > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> >
> >                 signal(SIGUSR1, load_helper_signal_handler);
> >                 signal(SIGUSR2, load_helper_signal_handler);
> > +               signal(SIGTERM, load_helper_signal_handler);
> 
> I don't see any behaviour changes to igt to cause it to send SIGTERM on
> exit_subtest.

Yes, exit_subtest() will not send SIGTERM out. But when main process calls
igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler() with SIGABORT.
(i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp, WNOHANG) == -1 && errno == ECHILD' failed.
Received signal SIGABRT.

In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
will send out the SIGTERM to all children process.

> 
> But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> intentions.
Don't get your real point, SIGUSR1 is for actively stopping load_helper, SIGUSR2 is for
switching high and low load, the SIGTERM is for passively exiting.


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

Re: [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Liu, Chuansheng]

Thanks for reviewing the patch, please see below comments.

> > So here we install the proper handler for signal SIGTERM in the
> > similar way. Without this patch, the GT may keep busy after
> > running this subtest. Enabling rps should be tracked on the
> > other side.
> >
> > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > ---
> >  tests/i915/i915_pm_rps.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > index ef627c0b..8c71c1a1 100644
> > --- a/tests/i915/i915_pm_rps.c
> > +++ b/tests/i915/i915_pm_rps.c
> > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> >
> >                 signal(SIGUSR1, load_helper_signal_handler);
> >                 signal(SIGUSR2, load_helper_signal_handler);
> > +               signal(SIGTERM, load_helper_signal_handler);
> 
> I don't see any behaviour changes to igt to cause it to send SIGTERM on
> exit_subtest.

Yes, exit_subtest() will not send SIGTERM out. But when main process calls
igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler() with SIGABORT.
(i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp, WNOHANG) == -1 && errno == ECHILD' failed.
Received signal SIGABRT.

In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
will send out the SIGTERM to all children process.

> 
> But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> intentions.
Don't get your real point, SIGUSR1 is for actively stopping load_helper, SIGUSR2 is for
switching high and low load, the SIGTERM is for passively exiting.


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

Re: [igt-dev] [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Liu, Chuansheng]

Thanks for reviewing the patch, please see below comments.

> > So here we install the proper handler for signal SIGTERM in the
> > similar way. Without this patch, the GT may keep busy after
> > running this subtest. Enabling rps should be tracked on the
> > other side.
> >
> > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > ---
> >  tests/i915/i915_pm_rps.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > index ef627c0b..8c71c1a1 100644
> > --- a/tests/i915/i915_pm_rps.c
> > +++ b/tests/i915/i915_pm_rps.c
> > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> >
> >                 signal(SIGUSR1, load_helper_signal_handler);
> >                 signal(SIGUSR2, load_helper_signal_handler);
> > +               signal(SIGTERM, load_helper_signal_handler);
> 
> I don't see any behaviour changes to igt to cause it to send SIGTERM on
> exit_subtest.

Yes, exit_subtest() will not send SIGTERM out. But when main process calls
igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler() with SIGABORT.
(i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp, WNOHANG) == -1 && errno == ECHILD' failed.
Received signal SIGABRT.

In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
will send out the SIGTERM to all children process.

> 
> But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> intentions.
Don't get your real point, SIGUSR1 is for actively stopping load_helper, SIGUSR2 is for
switching high and low load, the SIGTERM is for passively exiting.


_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chris Wilson]

Quoting Liu, Chuansheng (2019-11-21 01:34:24)
> Thanks for reviewing the patch, please see below comments.
> 
> > > So here we install the proper handler for signal SIGTERM in the
> > > similar way. Without this patch, the GT may keep busy after
> > > running this subtest. Enabling rps should be tracked on the
> > > other side.
> > >
> > > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > > ---
> > >  tests/i915/i915_pm_rps.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > > index ef627c0b..8c71c1a1 100644
> > > --- a/tests/i915/i915_pm_rps.c
> > > +++ b/tests/i915/i915_pm_rps.c
> > > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> > >
> > >                 signal(SIGUSR1, load_helper_signal_handler);
> > >                 signal(SIGUSR2, load_helper_signal_handler);
> > > +               signal(SIGTERM, load_helper_signal_handler);
> > 
> > I don't see any behaviour changes to igt to cause it to send SIGTERM on
> > exit_subtest.
> 
> Yes, exit_subtest() will not send SIGTERM out. But when main process calls
> igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler() with SIGABORT.
> (i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
> i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp, WNOHANG) == -1 && errno == ECHILD' failed.
> Received signal SIGABRT.

Ok, but that's not a huge concern, since we are already in an error state.
My concern is for fixing whatever got us into that state.

> In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
> will send out the SIGTERM to all children process.
> 
> > 
> > But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> > intentions.
> Don't get your real point, SIGUSR1 is for actively stopping load_helper, SIGUSR2 is for
> switching high and low load, the SIGTERM is for passively exiting.

I think the design of having a persistent helper process that leaks
between subtests is broken. Then using three signals for essentially only
2 commands is aesthetically unpleasing.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chris Wilson]

Quoting Liu, Chuansheng (2019-11-21 01:34:24)
> Thanks for reviewing the patch, please see below comments.
> 
> > > So here we install the proper handler for signal SIGTERM in the
> > > similar way. Without this patch, the GT may keep busy after
> > > running this subtest. Enabling rps should be tracked on the
> > > other side.
> > >
> > > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > > ---
> > >  tests/i915/i915_pm_rps.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > > index ef627c0b..8c71c1a1 100644
> > > --- a/tests/i915/i915_pm_rps.c
> > > +++ b/tests/i915/i915_pm_rps.c
> > > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> > >
> > >                 signal(SIGUSR1, load_helper_signal_handler);
> > >                 signal(SIGUSR2, load_helper_signal_handler);
> > > +               signal(SIGTERM, load_helper_signal_handler);
> > 
> > I don't see any behaviour changes to igt to cause it to send SIGTERM on
> > exit_subtest.
> 
> Yes, exit_subtest() will not send SIGTERM out. But when main process calls
> igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler() with SIGABORT.
> (i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
> i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp, WNOHANG) == -1 && errno == ECHILD' failed.
> Received signal SIGABRT.

Ok, but that's not a huge concern, since we are already in an error state.
My concern is for fixing whatever got us into that state.

> In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
> will send out the SIGTERM to all children process.
> 
> > 
> > But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> > intentions.
> Don't get your real point, SIGUSR1 is for actively stopping load_helper, SIGUSR2 is for
> switching high and low load, the SIGTERM is for passively exiting.

I think the design of having a persistent helper process that leaks
between subtests is broken. Then using three signals for essentially only
2 commands is aesthetically unpleasing.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [igt-dev] [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Chris Wilson]

Quoting Liu, Chuansheng (2019-11-21 01:34:24)
> Thanks for reviewing the patch, please see below comments.
> 
> > > So here we install the proper handler for signal SIGTERM in the
> > > similar way. Without this patch, the GT may keep busy after
> > > running this subtest. Enabling rps should be tracked on the
> > > other side.
> > >
> > > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > > ---
> > >  tests/i915/i915_pm_rps.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > > index ef627c0b..8c71c1a1 100644
> > > --- a/tests/i915/i915_pm_rps.c
> > > +++ b/tests/i915/i915_pm_rps.c
> > > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> > >
> > >                 signal(SIGUSR1, load_helper_signal_handler);
> > >                 signal(SIGUSR2, load_helper_signal_handler);
> > > +               signal(SIGTERM, load_helper_signal_handler);
> > 
> > I don't see any behaviour changes to igt to cause it to send SIGTERM on
> > exit_subtest.
> 
> Yes, exit_subtest() will not send SIGTERM out. But when main process calls
> igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler() with SIGABORT.
> (i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
> i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp, WNOHANG) == -1 && errno == ECHILD' failed.
> Received signal SIGABRT.

Ok, but that's not a huge concern, since we are already in an error state.
My concern is for fixing whatever got us into that state.

> In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
> will send out the SIGTERM to all children process.
> 
> > 
> > But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> > intentions.
> Don't get your real point, SIGUSR1 is for actively stopping load_helper, SIGUSR2 is for
> switching high and low load, the SIGTERM is for passively exiting.

I think the design of having a persistent helper process that leaks
between subtests is broken. Then using three signals for essentially only
2 commands is aesthetically unpleasing.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Liu, Chuansheng]

> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, November 21, 2019 3:47 PM
> To: Liu, Chuansheng <chuansheng.liu@intel.com>;
> igt-dev@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler
> for load_helper process
> 
> Quoting Liu, Chuansheng (2019-11-21 01:34:24)
> > Thanks for reviewing the patch, please see below comments.
> >
> > > > So here we install the proper handler for signal SIGTERM in the
> > > > similar way. Without this patch, the GT may keep busy after
> > > > running this subtest. Enabling rps should be tracked on the
> > > > other side.
> > > >
> > > > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > > > ---
> > > >  tests/i915/i915_pm_rps.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > > > index ef627c0b..8c71c1a1 100644
> > > > --- a/tests/i915/i915_pm_rps.c
> > > > +++ b/tests/i915/i915_pm_rps.c
> > > > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> > > >
> > > >                 signal(SIGUSR1, load_helper_signal_handler);
> > > >                 signal(SIGUSR2, load_helper_signal_handler);
> > > > +               signal(SIGTERM, load_helper_signal_handler);
> > >
> > > I don't see any behaviour changes to igt to cause it to send SIGTERM on
> > > exit_subtest.
> >
> > Yes, exit_subtest() will not send SIGTERM out. But when main process calls
> > igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler()
> with SIGABORT.
> > (i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
> > i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp,
> WNOHANG) == -1 && errno == ECHILD' failed.
> > Received signal SIGABRT.
> 
> Ok, but that's not a huge concern, since we are already in an error state.
> My concern is for fixing whatever got us into that state.
Agree. In this case, we need to enable rps completely. Here I would like this quick
patch to unblock the following test cases.

Without this quick fix, it can mislead guys to catch the real root cause:)
Would you mind to get this patch merged at first?

> 
> > In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
> > will send out the SIGTERM to all children process.
> >
> > >
> > > But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> > > intentions.
> > Don't get your real point, SIGUSR1 is for actively stopping load_helper,
> SIGUSR2 is for
> > switching high and low load, the SIGTERM is for passively exiting.
> 
> I think the design of having a persistent helper process that leaks
> between subtests is broken. Then using three signals for essentially only
> 2 commands is aesthetically unpleasing.
Yes, to be honest, the main process should not receive SIGABRT according
to the initial code intention. Since the children processes should be cleaned
up, no matter it is load_helper or other created children process.




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

Re: [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Liu, Chuansheng]

> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, November 21, 2019 3:47 PM
> To: Liu, Chuansheng <chuansheng.liu@intel.com>;
> igt-dev@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler
> for load_helper process
> 
> Quoting Liu, Chuansheng (2019-11-21 01:34:24)
> > Thanks for reviewing the patch, please see below comments.
> >
> > > > So here we install the proper handler for signal SIGTERM in the
> > > > similar way. Without this patch, the GT may keep busy after
> > > > running this subtest. Enabling rps should be tracked on the
> > > > other side.
> > > >
> > > > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > > > ---
> > > >  tests/i915/i915_pm_rps.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > > > index ef627c0b..8c71c1a1 100644
> > > > --- a/tests/i915/i915_pm_rps.c
> > > > +++ b/tests/i915/i915_pm_rps.c
> > > > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> > > >
> > > >                 signal(SIGUSR1, load_helper_signal_handler);
> > > >                 signal(SIGUSR2, load_helper_signal_handler);
> > > > +               signal(SIGTERM, load_helper_signal_handler);
> > >
> > > I don't see any behaviour changes to igt to cause it to send SIGTERM on
> > > exit_subtest.
> >
> > Yes, exit_subtest() will not send SIGTERM out. But when main process calls
> > igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler()
> with SIGABORT.
> > (i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
> > i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp,
> WNOHANG) == -1 && errno == ECHILD' failed.
> > Received signal SIGABRT.
> 
> Ok, but that's not a huge concern, since we are already in an error state.
> My concern is for fixing whatever got us into that state.
Agree. In this case, we need to enable rps completely. Here I would like this quick
patch to unblock the following test cases.

Without this quick fix, it can mislead guys to catch the real root cause:)
Would you mind to get this patch merged at first?

> 
> > In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
> > will send out the SIGTERM to all children process.
> >
> > >
> > > But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> > > intentions.
> > Don't get your real point, SIGUSR1 is for actively stopping load_helper,
> SIGUSR2 is for
> > switching high and low load, the SIGTERM is for passively exiting.
> 
> I think the design of having a persistent helper process that leaks
> between subtests is broken. Then using three signals for essentially only
> 2 commands is aesthetically unpleasing.
Yes, to be honest, the main process should not receive SIGABRT according
to the initial code intention. Since the children processes should be cleaned
up, no matter it is load_helper or other created children process.




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

Re: [igt-dev] [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler for load_helper process

[Liu, Chuansheng]

> -----Original Message-----
> From: Chris Wilson <chris@chris-wilson.co.uk>
> Sent: Thursday, November 21, 2019 3:47 PM
> To: Liu, Chuansheng <chuansheng.liu@intel.com>;
> igt-dev@lists.freedesktop.org
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH i-g-t v2] i915/pm_rps: install SIGTERM handler
> for load_helper process
> 
> Quoting Liu, Chuansheng (2019-11-21 01:34:24)
> > Thanks for reviewing the patch, please see below comments.
> >
> > > > So here we install the proper handler for signal SIGTERM in the
> > > > similar way. Without this patch, the GT may keep busy after
> > > > running this subtest. Enabling rps should be tracked on the
> > > > other side.
> > > >
> > > > Signed-off-by: Chuansheng Liu <chuansheng.liu@intel.com>
> > > > ---
> > > >  tests/i915/i915_pm_rps.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/tests/i915/i915_pm_rps.c b/tests/i915/i915_pm_rps.c
> > > > index ef627c0b..8c71c1a1 100644
> > > > --- a/tests/i915/i915_pm_rps.c
> > > > +++ b/tests/i915/i915_pm_rps.c
> > > > @@ -252,6 +252,7 @@ static void load_helper_run(enum load load)
> > > >
> > > >                 signal(SIGUSR1, load_helper_signal_handler);
> > > >                 signal(SIGUSR2, load_helper_signal_handler);
> > > > +               signal(SIGTERM, load_helper_signal_handler);
> > >
> > > I don't see any behaviour changes to igt to cause it to send SIGTERM on
> > > exit_subtest.
> >
> > Yes, exit_subtest() will not send SIGTERM out. But when main process calls
> > igt_exit() to exit, it hits the below assertion, then goes to fatal_sig_handler()
> with SIGABORT.
> > (i915_pm_rps:1680) igt_core-CRITICAL: Exiting with status code 98
> > i915_pm_rps: ../lib/igt_core.c:1775: igt_exit: Assertion `waitpid(-1, &tmp,
> WNOHANG) == -1 && errno == ECHILD' failed.
> > Received signal SIGABRT.
> 
> Ok, but that's not a huge concern, since we are already in an error state.
> My concern is for fixing whatever got us into that state.
Agree. In this case, we need to enable rps completely. Here I would like this quick
patch to unblock the following test cases.

Without this quick fix, it can mislead guys to catch the real root cause:)
Would you mind to get this patch merged at first?

> 
> > In fatal_sig_handler(), the installed exit handler fork_helper_exit_handler()
> > will send out the SIGTERM to all children process.
> >
> > >
> > > But you might as well just s/SIGUSR2/SIGTERM/ for clearer and common
> > > intentions.
> > Don't get your real point, SIGUSR1 is for actively stopping load_helper,
> SIGUSR2 is for
> > switching high and low load, the SIGTERM is for passively exiting.
> 
> I think the design of having a persistent helper process that leaks
> between subtests is broken. Then using three signals for essentially only
> 2 commands is aesthetically unpleasing.
Yes, to be honest, the main process should not receive SIGABRT according
to the initial code intention. Since the children processes should be cleaned
up, no matter it is load_helper or other created children process.




_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev