[igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Petri Latvala]

If a machine is hard-hanging or otherwise rebooted at the correct
time, intermediary output files get created but nothing ever gets
written to them. That yields results that are completely empty and
hard to categorize or even sometimes detect automatically. Handle this
corner case explicitly with a custom text explaining what might have
happened to prod result analysis towards fixing the real issue instead
of wondering if test result processing is faulty.

The race for getting empty files is easier to hit than it seems. The
files get created by the runner before calling exec(), and there's
plenty of time to hit a really hard crash.

Signed-off-by: Petri Latvala <petri.latvala@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
---
 .../empty-result-files/0/dmesg.txt            |  0
 .../empty-result-files/0/err.txt              |  0
 .../empty-result-files/0/journal.txt          |  0
 .../empty-result-files/0/out.txt              |  0
 .../empty-result-files/README.txt             |  2 +
 .../empty-result-files/endtime.txt            |  1 +
 .../empty-result-files/joblist.txt            |  1 +
 .../empty-result-files/metadata.txt           | 12 ++++
 .../empty-result-files/reference.json         | 59 +++++++++++++++++++
 .../empty-result-files/starttime.txt          |  1 +
 .../empty-result-files/uname.txt              |  1 +
 runner/resultgen.c                            | 25 ++++++++
 runner/runner_json_tests.c                    |  1 +
 13 files changed, 103 insertions(+)
 create mode 100644 runner/json_tests_data/empty-result-files/0/dmesg.txt
 create mode 100644 runner/json_tests_data/empty-result-files/0/err.txt
 create mode 100644 runner/json_tests_data/empty-result-files/0/journal.txt
 create mode 100644 runner/json_tests_data/empty-result-files/0/out.txt
 create mode 100644 runner/json_tests_data/empty-result-files/README.txt
 create mode 100644 runner/json_tests_data/empty-result-files/endtime.txt
 create mode 100644 runner/json_tests_data/empty-result-files/joblist.txt
 create mode 100644 runner/json_tests_data/empty-result-files/metadata.txt
 create mode 100644 runner/json_tests_data/empty-result-files/reference.json
 create mode 100644 runner/json_tests_data/empty-result-files/starttime.txt
 create mode 100644 runner/json_tests_data/empty-result-files/uname.txt

diff --git a/runner/json_tests_data/empty-result-files/0/dmesg.txt b/runner/json_tests_data/empty-result-files/0/dmesg.txt
new file mode 100644
index 00000000..e69de29b
diff --git a/runner/json_tests_data/empty-result-files/0/err.txt b/runner/json_tests_data/empty-result-files/0/err.txt
new file mode 100644
index 00000000..e69de29b
diff --git a/runner/json_tests_data/empty-result-files/0/journal.txt b/runner/json_tests_data/empty-result-files/0/journal.txt
new file mode 100644
index 00000000..e69de29b
diff --git a/runner/json_tests_data/empty-result-files/0/out.txt b/runner/json_tests_data/empty-result-files/0/out.txt
new file mode 100644
index 00000000..e69de29b
diff --git a/runner/json_tests_data/empty-result-files/README.txt b/runner/json_tests_data/empty-result-files/README.txt
new file mode 100644
index 00000000..c0266342
--- /dev/null
+++ b/runner/json_tests_data/empty-result-files/README.txt
@@ -0,0 +1,2 @@
+A run that rebooted just when a test was about to launch produces just
+empty intermediary result files that get special processing.
diff --git a/runner/json_tests_data/empty-result-files/endtime.txt b/runner/json_tests_data/empty-result-files/endtime.txt
new file mode 100644
index 00000000..635f6ae9
--- /dev/null
+++ b/runner/json_tests_data/empty-result-files/endtime.txt
@@ -0,0 +1 @@
+1539953735.172373
diff --git a/runner/json_tests_data/empty-result-files/joblist.txt b/runner/json_tests_data/empty-result-files/joblist.txt
new file mode 100644
index 00000000..81f914a7
--- /dev/null
+++ b/runner/json_tests_data/empty-result-files/joblist.txt
@@ -0,0 +1 @@
+successtest first-subtest
diff --git a/runner/json_tests_data/empty-result-files/metadata.txt b/runner/json_tests_data/empty-result-files/metadata.txt
new file mode 100644
index 00000000..ef7eddb6
--- /dev/null
+++ b/runner/json_tests_data/empty-result-files/metadata.txt
@@ -0,0 +1,12 @@
+abort_mask : 0
+name : empty-result-files
+dry_run : 0
+sync : 0
+log_level : 0
+overwrite : 0
+multiple_mode : 0
+inactivity_timeout : 0
+use_watchdog : 0
+piglit_style_dmesg : 0
+test_root : /path/does/not/exist
+results_path : /path/does/not/exist
diff --git a/runner/json_tests_data/empty-result-files/reference.json b/runner/json_tests_data/empty-result-files/reference.json
new file mode 100644
index 00000000..ef225601
--- /dev/null
+++ b/runner/json_tests_data/empty-result-files/reference.json
@@ -0,0 +1,59 @@
+{
+  "__type__":"TestrunResult",
+  "results_version":10,
+  "name":"empty-result-files",
+  "uname":"Linux hostname 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64",
+  "time_elapsed":{
+    "__type__":"TimeAttribute",
+    "start":1539953735.1110389,
+    "end":1539953735.1723731
+  },
+  "tests":{
+    "igt@successtest@first-subtest":{
+	"out":"This test didn't produce any output. The machine probably rebooted ungracefully.\n",
+	"err":"",
+	"dmesg":"",
+	"result":"incomplete"
+    },
+  },
+  "totals":{
+    "":{
+      "crash":0,
+      "pass":0,
+      "dmesg-fail":0,
+      "dmesg-warn":0,
+      "skip":0,
+      "incomplete":1,
+      "timeout":0,
+      "notrun":0,
+      "fail":0,
+      "warn":0
+    },
+    "root":{
+      "crash":0,
+      "pass":0,
+      "dmesg-fail":0,
+      "dmesg-warn":0,
+      "skip":0,
+      "incomplete":1,
+      "timeout":0,
+      "notrun":0,
+      "fail":0,
+      "warn":0
+    },
+    "igt@successtest":{
+      "crash":0,
+      "pass":0,
+      "dmesg-fail":0,
+      "dmesg-warn":0,
+      "skip":0,
+      "incomplete":1,
+      "timeout":0,
+      "notrun":0,
+      "fail":0,
+      "warn":0
+    },
+  },
+  "runtimes":{
+  }
+}
diff --git a/runner/json_tests_data/empty-result-files/starttime.txt b/runner/json_tests_data/empty-result-files/starttime.txt
new file mode 100644
index 00000000..ae038f18
--- /dev/null
+++ b/runner/json_tests_data/empty-result-files/starttime.txt
@@ -0,0 +1 @@
+1539953735.111039
diff --git a/runner/json_tests_data/empty-result-files/uname.txt b/runner/json_tests_data/empty-result-files/uname.txt
new file mode 100644
index 00000000..a7aef6f7
--- /dev/null
+++ b/runner/json_tests_data/empty-result-files/uname.txt
@@ -0,0 +1 @@
+Linux hostname 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64
diff --git a/runner/resultgen.c b/runner/resultgen.c
index 105ec887..611d36cb 100644
--- a/runner/resultgen.c
+++ b/runner/resultgen.c
@@ -1220,6 +1220,29 @@ static bool stderr_contains_warnings(const char *beg, const char *end)
 	return false;
 }
 
+static bool json_field_has_data(struct json_object *obj, const char *key)
+{
+	struct json_object *field;
+
+	if (json_object_object_get_ex(obj, key, &field))
+		return strcmp(json_object_get_string(field), "");
+
+	return false;
+}
+
+static void override_completely_empty_results(struct json_object *obj)
+{
+	if (json_field_has_data(obj, "out") ||
+	    json_field_has_data(obj, "err") ||
+	    json_field_has_data(obj, "dmesg"))
+		return;
+
+	json_object_object_add(obj, "out",
+			       json_object_new_string("This test didn't produce any output. "
+						      "The machine probably rebooted ungracefully.\n"));
+	set_result(obj, "incomplete");
+}
+
 static void override_result_single(struct json_object *obj)
 {
 	const char *errtext = "", *result = "";
@@ -1246,6 +1269,8 @@ static void override_result_single(struct json_object *obj)
 			set_result(obj, "dmesg-fail");
 		}
 	}
+
+	override_completely_empty_results(obj);
 }
 
 static void override_results(char *binary,
diff --git a/runner/runner_json_tests.c b/runner/runner_json_tests.c
index bf4c285b..a7a1e8de 100644
--- a/runner/runner_json_tests.c
+++ b/runner/runner_json_tests.c
@@ -165,6 +165,7 @@ static const char *dirnames[] = {
 	"dynamic-subtests",
 	"dynamic-subtest-name-in-multiple-subtests",
 	"unprintable-characters",
+	"empty-result-files",
 };
 
 igt_main
-- 
2.20.1

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

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Arkadiusz Hiler]

On Wed, Feb 19, 2020 at 02:19:40PM +0200, Petri Latvala wrote:
> If a machine is hard-hanging or otherwise rebooted at the correct
> time, intermediary output files get created but nothing ever gets
> written to them. That yields results that are completely empty and
> hard to categorize or even sometimes detect automatically. Handle this
> corner case explicitly with a custom text explaining what might have
> happened to prod result analysis towards fixing the real issue instead
> of wondering if test result processing is faulty.
> 
> The race for getting empty files is easier to hit than it seems. The
> files get created by the runner before calling exec(), and there's
> plenty of time to hit a really hard crash.
> 
> Signed-off-by: Petri Latvala <petri.latvala@intel.com>
> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

[igt-dev] ✓ Fi.CI.BAT: success for runner/resultgen: Provide output when test output is completely empty

[Patchwork]

== Series Details ==

Series: runner/resultgen: Provide output when test output is completely empty
URL   : https://patchwork.freedesktop.org/series/73643/
State : success

== Summary ==

CI Bug Log - changes from IGT_5450 -> IGTPW_4184
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_close_race@basic-threads:
    - fi-hsw-peppy:       [PASS][1] -> [INCOMPLETE][2] ([i915#694] / [i915#816])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/fi-hsw-peppy/igt@gem_close_race@basic-threads.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/fi-hsw-peppy/igt@gem_close_race@basic-threads.html

  
#### Warnings ####

  * igt@gem_exec_parallel@fds:
    - fi-byt-n2820:       [FAIL][3] ([i915#694]) -> [TIMEOUT][4] ([fdo#112271])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/fi-byt-n2820/igt@gem_exec_parallel@fds.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/fi-byt-n2820/igt@gem_exec_parallel@fds.html

  
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
  [i915#816]: https://gitlab.freedesktop.org/drm/intel/issues/816


Participating hosts (51 -> 45)
------------------------------

  Additional (2): fi-bwr-2160 fi-snb-2520m 
  Missing    (8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-8700k fi-ctg-p8600 fi-byt-clapper fi-bdw-samus 


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

  * CI: CI-20190529 -> None
  * IGT: IGT_5450 -> IGTPW_4184

  CI-20190529: 20190529
  CI_DRM_7963: e0d737598eb749378a5dc4ed3dfafc6f79d512cb @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4184: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/index.html
  IGT_5450: dfba090e720ed4e043158887f1ba6a76059491e8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Chris Wilson]

Quoting Petri Latvala (2020-02-19 12:19:40)
> If a machine is hard-hanging or otherwise rebooted at the correct
> time, intermediary output files get created but nothing ever gets
> written to them. That yields results that are completely empty and
> hard to categorize or even sometimes detect automatically. Handle this
> corner case explicitly with a custom text explaining what might have
> happened to prod result analysis towards fixing the real issue instead
> of wondering if test result processing is faulty.
> 
> The race for getting empty files is easier to hit than it seems. The
> files get created by the runner before calling exec(), and there's
> plenty of time to hit a really hard crash.

Speaking of which, it would not be terrible if igt_runner periodically
called sync() everytime it decided there were new logs to preserve.
We should also probably remove/reduce the writeback delay.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Petri Latvala]

On Wed, Feb 19, 2020 at 01:23:22PM +0000, Chris Wilson wrote:
> Quoting Petri Latvala (2020-02-19 12:19:40)
> > If a machine is hard-hanging or otherwise rebooted at the correct
> > time, intermediary output files get created but nothing ever gets
> > written to them. That yields results that are completely empty and
> > hard to categorize or even sometimes detect automatically. Handle this
> > corner case explicitly with a custom text explaining what might have
> > happened to prod result analysis towards fixing the real issue instead
> > of wondering if test result processing is faulty.
> > 
> > The race for getting empty files is easier to hit than it seems. The
> > files get created by the runner before calling exec(), and there's
> > plenty of time to hit a really hard crash.
> 
> Speaking of which, it would not be terrible if igt_runner periodically
> called sync() everytime it decided there were new logs to preserve.
> We should also probably remove/reduce the writeback delay.


Does calling sync() sync more than fsyncdata()?


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

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Chris Wilson]

Quoting Petri Latvala (2020-02-19 13:27:58)
> On Wed, Feb 19, 2020 at 01:23:22PM +0000, Chris Wilson wrote:
> > Quoting Petri Latvala (2020-02-19 12:19:40)
> > > If a machine is hard-hanging or otherwise rebooted at the correct
> > > time, intermediary output files get created but nothing ever gets
> > > written to them. That yields results that are completely empty and
> > > hard to categorize or even sometimes detect automatically. Handle this
> > > corner case explicitly with a custom text explaining what might have
> > > happened to prod result analysis towards fixing the real issue instead
> > > of wondering if test result processing is faulty.
> > > 
> > > The race for getting empty files is easier to hit than it seems. The
> > > files get created by the runner before calling exec(), and there's
> > > plenty of time to hit a really hard crash.
> > 
> > Speaking of which, it would not be terrible if igt_runner periodically
> > called sync() everytime it decided there were new logs to preserve.
> > We should also probably remove/reduce the writeback delay.
> 
> 
> Does calling sync() sync more than fsyncdata()?

No manual entry for fsyncdata(), fdatasync()?
sync/fsync includes metadata, fdatasync is just contents, unless
metadata is required for data retrieval.

So for us, there really shouldn't be any difference between fdatasync
and fsync (with the slight exception of last access timestamps).
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Petri Latvala]

On Wed, Feb 19, 2020 at 01:33:15PM +0000, Chris Wilson wrote:
> Quoting Petri Latvala (2020-02-19 13:27:58)
> > On Wed, Feb 19, 2020 at 01:23:22PM +0000, Chris Wilson wrote:
> > > Quoting Petri Latvala (2020-02-19 12:19:40)
> > > > If a machine is hard-hanging or otherwise rebooted at the correct
> > > > time, intermediary output files get created but nothing ever gets
> > > > written to them. That yields results that are completely empty and
> > > > hard to categorize or even sometimes detect automatically. Handle this
> > > > corner case explicitly with a custom text explaining what might have
> > > > happened to prod result analysis towards fixing the real issue instead
> > > > of wondering if test result processing is faulty.
> > > > 
> > > > The race for getting empty files is easier to hit than it seems. The
> > > > files get created by the runner before calling exec(), and there's
> > > > plenty of time to hit a really hard crash.
> > > 
> > > Speaking of which, it would not be terrible if igt_runner periodically
> > > called sync() everytime it decided there were new logs to preserve.
> > > We should also probably remove/reduce the writeback delay.
> > 
> > 
> > Does calling sync() sync more than fsyncdata()?
> 
> No manual entry for fsyncdata(), fdatasync()?
> sync/fsync includes metadata, fdatasync is just contents, unless
> metadata is required for data retrieval.
> 
> So for us, there really shouldn't be any difference between fdatasync
> and fsync (with the slight exception of last access timestamps).

Then what you're asking for is already there with --sync.


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

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Chris Wilson]

Quoting Petri Latvala (2020-02-19 13:45:03)
> On Wed, Feb 19, 2020 at 01:33:15PM +0000, Chris Wilson wrote:
> > Quoting Petri Latvala (2020-02-19 13:27:58)
> > > On Wed, Feb 19, 2020 at 01:23:22PM +0000, Chris Wilson wrote:
> > > > Quoting Petri Latvala (2020-02-19 12:19:40)
> > > > > If a machine is hard-hanging or otherwise rebooted at the correct
> > > > > time, intermediary output files get created but nothing ever gets
> > > > > written to them. That yields results that are completely empty and
> > > > > hard to categorize or even sometimes detect automatically. Handle this
> > > > > corner case explicitly with a custom text explaining what might have
> > > > > happened to prod result analysis towards fixing the real issue instead
> > > > > of wondering if test result processing is faulty.
> > > > > 
> > > > > The race for getting empty files is easier to hit than it seems. The
> > > > > files get created by the runner before calling exec(), and there's
> > > > > plenty of time to hit a really hard crash.
> > > > 
> > > > Speaking of which, it would not be terrible if igt_runner periodically
> > > > called sync() everytime it decided there were new logs to preserve.
> > > > We should also probably remove/reduce the writeback delay.
> > > 
> > > 
> > > Does calling sync() sync more than fsyncdata()?
> > 
> > No manual entry for fsyncdata(), fdatasync()?
> > sync/fsync includes metadata, fdatasync is just contents, unless
> > metadata is required for data retrieval.
> > 
> > So for us, there really shouldn't be any difference between fdatasync
> > and fsync (with the slight exception of last access timestamps).
> 
> Then what you're asking for is already there with --sync.

Do we use it? :)
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Chris Wilson]

Quoting Chris Wilson (2020-02-19 13:46:38)
> Quoting Petri Latvala (2020-02-19 13:45:03)
> > On Wed, Feb 19, 2020 at 01:33:15PM +0000, Chris Wilson wrote:
> > > Quoting Petri Latvala (2020-02-19 13:27:58)
> > > > On Wed, Feb 19, 2020 at 01:23:22PM +0000, Chris Wilson wrote:
> > > > > Quoting Petri Latvala (2020-02-19 12:19:40)
> > > > > > If a machine is hard-hanging or otherwise rebooted at the correct
> > > > > > time, intermediary output files get created but nothing ever gets
> > > > > > written to them. That yields results that are completely empty and
> > > > > > hard to categorize or even sometimes detect automatically. Handle this
> > > > > > corner case explicitly with a custom text explaining what might have
> > > > > > happened to prod result analysis towards fixing the real issue instead
> > > > > > of wondering if test result processing is faulty.
> > > > > > 
> > > > > > The race for getting empty files is easier to hit than it seems. The
> > > > > > files get created by the runner before calling exec(), and there's
> > > > > > plenty of time to hit a really hard crash.
> > > > > 
> > > > > Speaking of which, it would not be terrible if igt_runner periodically
> > > > > called sync() everytime it decided there were new logs to preserve.
> > > > > We should also probably remove/reduce the writeback delay.
> > > > 
> > > > 
> > > > Does calling sync() sync more than fsyncdata()?
> > > 
> > > No manual entry for fsyncdata(), fdatasync()?
> > > sync/fsync includes metadata, fdatasync is just contents, unless
> > > metadata is required for data retrieval.
> > > 
> > > So for us, there really shouldn't be any difference between fdatasync
> > > and fsync (with the slight exception of last access timestamps).
> > 
> > Then what you're asking for is already there with --sync.
> 
> Do we use it? :)

I see that fdatasync() is used on the runner's output; are they all the
files that are retrieved after a crash? I'd feel more comfortable with
sync() as we purposefully do crash the system.
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Petri Latvala]

On Wed, Feb 19, 2020 at 01:50:14PM +0000, Chris Wilson wrote:
> Quoting Chris Wilson (2020-02-19 13:46:38)
> > Quoting Petri Latvala (2020-02-19 13:45:03)
> > > On Wed, Feb 19, 2020 at 01:33:15PM +0000, Chris Wilson wrote:
> > > > Quoting Petri Latvala (2020-02-19 13:27:58)
> > > > > On Wed, Feb 19, 2020 at 01:23:22PM +0000, Chris Wilson wrote:
> > > > > > Quoting Petri Latvala (2020-02-19 12:19:40)
> > > > > > > If a machine is hard-hanging or otherwise rebooted at the correct
> > > > > > > time, intermediary output files get created but nothing ever gets
> > > > > > > written to them. That yields results that are completely empty and
> > > > > > > hard to categorize or even sometimes detect automatically. Handle this
> > > > > > > corner case explicitly with a custom text explaining what might have
> > > > > > > happened to prod result analysis towards fixing the real issue instead
> > > > > > > of wondering if test result processing is faulty.
> > > > > > > 
> > > > > > > The race for getting empty files is easier to hit than it seems. The
> > > > > > > files get created by the runner before calling exec(), and there's
> > > > > > > plenty of time to hit a really hard crash.
> > > > > > 
> > > > > > Speaking of which, it would not be terrible if igt_runner periodically
> > > > > > called sync() everytime it decided there were new logs to preserve.
> > > > > > We should also probably remove/reduce the writeback delay.
> > > > > 
> > > > > 
> > > > > Does calling sync() sync more than fsyncdata()?
> > > > 
> > > > No manual entry for fsyncdata(), fdatasync()?
> > > > sync/fsync includes metadata, fdatasync is just contents, unless
> > > > metadata is required for data retrieval.
> > > > 
> > > > So for us, there really shouldn't be any difference between fdatasync
> > > > and fsync (with the slight exception of last access timestamps).
> > > 
> > > Then what you're asking for is already there with --sync.
> > 
> > Do we use it? :)
> 
> I see that fdatasync() is used on the runner's output; are they all the
> files that are retrieved after a crash? I'd feel more comfortable with
> sync() as we purposefully do crash the system.

Yeah, any output written gets fdatasync()d immediately.


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

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Chris Wilson]

Quoting Petri Latvala (2020-02-19 13:56:59)
> On Wed, Feb 19, 2020 at 01:50:14PM +0000, Chris Wilson wrote:
> > Quoting Chris Wilson (2020-02-19 13:46:38)
> > > Quoting Petri Latvala (2020-02-19 13:45:03)
> > > > On Wed, Feb 19, 2020 at 01:33:15PM +0000, Chris Wilson wrote:
> > > > > Quoting Petri Latvala (2020-02-19 13:27:58)
> > > > > > On Wed, Feb 19, 2020 at 01:23:22PM +0000, Chris Wilson wrote:
> > > > > > > Quoting Petri Latvala (2020-02-19 12:19:40)
> > > > > > > > If a machine is hard-hanging or otherwise rebooted at the correct
> > > > > > > > time, intermediary output files get created but nothing ever gets
> > > > > > > > written to them. That yields results that are completely empty and
> > > > > > > > hard to categorize or even sometimes detect automatically. Handle this
> > > > > > > > corner case explicitly with a custom text explaining what might have
> > > > > > > > happened to prod result analysis towards fixing the real issue instead
> > > > > > > > of wondering if test result processing is faulty.
> > > > > > > > 
> > > > > > > > The race for getting empty files is easier to hit than it seems. The
> > > > > > > > files get created by the runner before calling exec(), and there's
> > > > > > > > plenty of time to hit a really hard crash.
> > > > > > > 
> > > > > > > Speaking of which, it would not be terrible if igt_runner periodically
> > > > > > > called sync() everytime it decided there were new logs to preserve.
> > > > > > > We should also probably remove/reduce the writeback delay.
> > > > > > 
> > > > > > 
> > > > > > Does calling sync() sync more than fsyncdata()?
> > > > > 
> > > > > No manual entry for fsyncdata(), fdatasync()?
> > > > > sync/fsync includes metadata, fdatasync is just contents, unless
> > > > > metadata is required for data retrieval.
> > > > > 
> > > > > So for us, there really shouldn't be any difference between fdatasync
> > > > > and fsync (with the slight exception of last access timestamps).
> > > > 
> > > > Then what you're asking for is already there with --sync.
> > > 
> > > Do we use it? :)
> > 
> > I see that fdatasync() is used on the runner's output; are they all the
> > files that are retrieved after a crash? I'd feel more comfortable with
> > sync() as we purposefully do crash the system.
> 
> Yeah, any output written gets fdatasync()d immediately.

What about dmesg? Is that pulled from the runner's logs or from syslog?
I ask because we quite frequently see lost output in dmesg.txt
-Chris
_______________________________________________
igt-dev mailing list
igt-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/igt-dev

Re: [igt-dev] [PATCH i-g-t] runner/resultgen: Provide output when test output is completely empty

[Petri Latvala]

On Wed, Feb 19, 2020 at 01:59:55PM +0000, Chris Wilson wrote:
> Quoting Petri Latvala (2020-02-19 13:56:59)
> > On Wed, Feb 19, 2020 at 01:50:14PM +0000, Chris Wilson wrote:
> > > Quoting Chris Wilson (2020-02-19 13:46:38)
> > > > Quoting Petri Latvala (2020-02-19 13:45:03)
> > > > > On Wed, Feb 19, 2020 at 01:33:15PM +0000, Chris Wilson wrote:
> > > > > > Quoting Petri Latvala (2020-02-19 13:27:58)
> > > > > > > On Wed, Feb 19, 2020 at 01:23:22PM +0000, Chris Wilson wrote:
> > > > > > > > Quoting Petri Latvala (2020-02-19 12:19:40)
> > > > > > > > > If a machine is hard-hanging or otherwise rebooted at the correct
> > > > > > > > > time, intermediary output files get created but nothing ever gets
> > > > > > > > > written to them. That yields results that are completely empty and
> > > > > > > > > hard to categorize or even sometimes detect automatically. Handle this
> > > > > > > > > corner case explicitly with a custom text explaining what might have
> > > > > > > > > happened to prod result analysis towards fixing the real issue instead
> > > > > > > > > of wondering if test result processing is faulty.
> > > > > > > > > 
> > > > > > > > > The race for getting empty files is easier to hit than it seems. The
> > > > > > > > > files get created by the runner before calling exec(), and there's
> > > > > > > > > plenty of time to hit a really hard crash.
> > > > > > > > 
> > > > > > > > Speaking of which, it would not be terrible if igt_runner periodically
> > > > > > > > called sync() everytime it decided there were new logs to preserve.
> > > > > > > > We should also probably remove/reduce the writeback delay.
> > > > > > > 
> > > > > > > 
> > > > > > > Does calling sync() sync more than fsyncdata()?
> > > > > > 
> > > > > > No manual entry for fsyncdata(), fdatasync()?
> > > > > > sync/fsync includes metadata, fdatasync is just contents, unless
> > > > > > metadata is required for data retrieval.
> > > > > > 
> > > > > > So for us, there really shouldn't be any difference between fdatasync
> > > > > > and fsync (with the slight exception of last access timestamps).
> > > > > 
> > > > > Then what you're asking for is already there with --sync.
> > > > 
> > > > Do we use it? :)
> > > 
> > > I see that fdatasync() is used on the runner's output; are they all the
> > > files that are retrieved after a crash? I'd feel more comfortable with
> > > sync() as we purposefully do crash the system.
> > 
> > Yeah, any output written gets fdatasync()d immediately.
> 
> What about dmesg? Is that pulled from the runner's logs or from syslog?
> I ask because we quite frequently see lost output in dmesg.txt

From /dev/kmsg directly. Reason for the discrepancy between runner's
kernel logs and dmesg.txt is beyond me.

Btw I've seen the difference go both ways so it's even more confusing.


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

[igt-dev] ✓ Fi.CI.IGT: success for runner/resultgen: Provide output when test output is completely empty

[Patchwork]

== Series Details ==

Series: runner/resultgen: Provide output when test output is completely empty
URL   : https://patchwork.freedesktop.org/series/73643/
State : success

== Summary ==

CI Bug Log - changes from IGT_5450_full -> IGTPW_4184_full
====================================================

Summary
-------

  **SUCCESS**

  No regressions found.

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

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_exec_schedule@pi-distinct-iova-bsd:
    - shard-iclb:         [PASS][1] -> [SKIP][2] ([i915#677])
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb6/igt@gem_exec_schedule@pi-distinct-iova-bsd.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb1/igt@gem_exec_schedule@pi-distinct-iova-bsd.html

  * igt@gem_exec_schedule@preempt-contexts-bsd2:
    - shard-iclb:         [PASS][3] -> [SKIP][4] ([fdo#109276]) +19 similar issues
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb2/igt@gem_exec_schedule@preempt-contexts-bsd2.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb5/igt@gem_exec_schedule@preempt-contexts-bsd2.html

  * igt@gem_exec_schedule@preempt-other-chain-bsd:
    - shard-iclb:         [PASS][5] -> [SKIP][6] ([fdo#112146]) +1 similar issue
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb8/igt@gem_exec_schedule@preempt-other-chain-bsd.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb2/igt@gem_exec_schedule@preempt-other-chain-bsd.html

  * igt@gem_render_copy_redux@interruptible:
    - shard-hsw:          [PASS][7] -> [FAIL][8] ([i915#910])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-hsw6/igt@gem_render_copy_redux@interruptible.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-hsw6/igt@gem_render_copy_redux@interruptible.html

  * igt@i915_pm_dc@dc6-dpms:
    - shard-iclb:         [PASS][9] -> [FAIL][10] ([i915#454])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb6/igt@i915_pm_dc@dc6-dpms.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb3/igt@i915_pm_dc@dc6-dpms.html

  * igt@kms_cursor_crc@pipe-a-cursor-suspend:
    - shard-kbl:          [PASS][11] -> [DMESG-WARN][12] ([i915#180]) +6 similar issues
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-kbl3/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-kbl7/igt@kms_cursor_crc@pipe-a-cursor-suspend.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding:
    - shard-kbl:          [PASS][13] -> [FAIL][14] ([i915#54])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-kbl4/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-kbl7/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
    - shard-apl:          [PASS][15] -> [FAIL][16] ([i915#54])
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-apl1/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-apl8/igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding.html

  * igt@kms_cursor_crc@pipe-c-cursor-suspend:
    - shard-apl:          [PASS][17] -> [DMESG-WARN][18] ([i915#180])
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-apl2/igt@kms_cursor_crc@pipe-c-cursor-suspend.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-apl4/igt@kms_cursor_crc@pipe-c-cursor-suspend.html

  * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic:
    - shard-hsw:          [PASS][19] -> [FAIL][20] ([i915#96])
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-hsw7/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-hsw8/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic.html

  * igt@kms_flip@2x-plain-flip-fb-recreate-interruptible:
    - shard-glk:          [PASS][21] -> [FAIL][22] ([i915#34])
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-glk7/igt@kms_flip@2x-plain-flip-fb-recreate-interruptible.html

  * igt@kms_psr@psr2_cursor_render:
    - shard-iclb:         [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue
   [23]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
   [24]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb1/igt@kms_psr@psr2_cursor_render.html

  * igt@perf@oa-exponents:
    - shard-glk:          [PASS][25] -> [FAIL][26] ([i915#84])
   [25]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-glk3/igt@perf@oa-exponents.html
   [26]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-glk5/igt@perf@oa-exponents.html

  * igt@perf_pmu@busy-no-semaphores-vcs1:
    - shard-iclb:         [PASS][27] -> [SKIP][28] ([fdo#112080]) +14 similar issues
   [27]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb4/igt@perf_pmu@busy-no-semaphores-vcs1.html
   [28]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb7/igt@perf_pmu@busy-no-semaphores-vcs1.html

  
#### Possible fixes ####

  * igt@gem_ctx_isolation@vcs1-dirty-create:
    - shard-iclb:         [SKIP][29] ([fdo#112080]) -> [PASS][30] +11 similar issues
   [29]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb6/igt@gem_ctx_isolation@vcs1-dirty-create.html
   [30]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb2/igt@gem_ctx_isolation@vcs1-dirty-create.html

  * igt@gem_exec_balancer@hang:
    - shard-iclb:         [FAIL][31] -> [PASS][32]
   [31]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb1/igt@gem_exec_balancer@hang.html
   [32]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb6/igt@gem_exec_balancer@hang.html

  * igt@gem_exec_balancer@smoke:
    - shard-iclb:         [SKIP][33] ([fdo#110854]) -> [PASS][34]
   [33]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb7/igt@gem_exec_balancer@smoke.html
   [34]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb4/igt@gem_exec_balancer@smoke.html

  * {igt@gem_exec_schedule@implicit-both-bsd1}:
    - shard-iclb:         [SKIP][35] ([fdo#109276] / [i915#677]) -> [PASS][36] +3 similar issues
   [35]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb8/igt@gem_exec_schedule@implicit-both-bsd1.html
   [36]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb1/igt@gem_exec_schedule@implicit-both-bsd1.html

  * igt@gem_exec_schedule@pi-common-bsd:
    - shard-iclb:         [SKIP][37] ([i915#677]) -> [PASS][38] +1 similar issue
   [37]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb4/igt@gem_exec_schedule@pi-common-bsd.html
   [38]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb5/igt@gem_exec_schedule@pi-common-bsd.html

  * igt@gem_exec_schedule@reorder-wide-bsd:
    - shard-iclb:         [SKIP][39] ([fdo#112146]) -> [PASS][40] +6 similar issues
   [39]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb2/igt@gem_exec_schedule@reorder-wide-bsd.html
   [40]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb6/igt@gem_exec_schedule@reorder-wide-bsd.html

  * igt@gem_partial_pwrite_pread@writes-after-reads:
    - shard-hsw:          [FAIL][41] ([i915#694]) -> [PASS][42] +2 similar issues
   [41]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-hsw6/igt@gem_partial_pwrite_pread@writes-after-reads.html
   [42]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-hsw8/igt@gem_partial_pwrite_pread@writes-after-reads.html

  * igt@gem_softpin@noreloc-s3:
    - shard-apl:          [DMESG-WARN][43] ([i915#180]) -> [PASS][44] +2 similar issues
   [43]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-apl6/igt@gem_softpin@noreloc-s3.html
   [44]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-apl7/igt@gem_softpin@noreloc-s3.html

  * igt@gem_workarounds@suspend-resume:
    - shard-apl:          [INCOMPLETE][45] ([fdo#103927]) -> [PASS][46]
   [45]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-apl8/igt@gem_workarounds@suspend-resume.html
   [46]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-apl3/igt@gem_workarounds@suspend-resume.html

  * igt@i915_selftest@live_gtt:
    - shard-apl:          [TIMEOUT][47] ([fdo#112271]) -> [PASS][48]
   [47]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-apl3/igt@i915_selftest@live_gtt.html
   [48]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-apl2/igt@i915_selftest@live_gtt.html

  * igt@kms_cursor_crc@pipe-b-cursor-128x42-sliding:
    - shard-kbl:          [FAIL][49] ([i915#54]) -> [PASS][50]
   [49]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-kbl2/igt@kms_cursor_crc@pipe-b-cursor-128x42-sliding.html
   [50]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-kbl7/igt@kms_cursor_crc@pipe-b-cursor-128x42-sliding.html
    - shard-apl:          [FAIL][51] ([i915#54]) -> [PASS][52]
   [51]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-apl2/igt@kms_cursor_crc@pipe-b-cursor-128x42-sliding.html
   [52]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-apl6/igt@kms_cursor_crc@pipe-b-cursor-128x42-sliding.html

  * igt@kms_frontbuffer_tracking@fbcpsr-slowdraw:
    - shard-tglb:         [SKIP][53] ([i915#668]) -> [PASS][54] +2 similar issues
   [53]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-slowdraw.html
   [54]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-tglb3/igt@kms_frontbuffer_tracking@fbcpsr-slowdraw.html

  * {igt@kms_hdr@bpc-switch-suspend}:
    - shard-kbl:          [DMESG-WARN][55] ([i915#180]) -> [PASS][56] +3 similar issues
   [55]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-kbl4/igt@kms_hdr@bpc-switch-suspend.html
   [56]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-kbl4/igt@kms_hdr@bpc-switch-suspend.html

  * igt@kms_plane_lowres@pipe-a-tiling-x:
    - shard-glk:          [FAIL][57] ([i915#899]) -> [PASS][58]
   [57]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-glk3/igt@kms_plane_lowres@pipe-a-tiling-x.html
   [58]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-glk2/igt@kms_plane_lowres@pipe-a-tiling-x.html

  * igt@kms_psr@psr2_no_drrs:
    - shard-iclb:         [SKIP][59] ([fdo#109441]) -> [PASS][60] +2 similar issues
   [59]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb8/igt@kms_psr@psr2_no_drrs.html
   [60]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb2/igt@kms_psr@psr2_no_drrs.html

  * igt@perf@gen12-mi-rpc:
    - shard-tglb:         [TIMEOUT][61] ([fdo#112271] / [i915#1085]) -> [PASS][62]
   [61]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-tglb6/igt@perf@gen12-mi-rpc.html
   [62]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-tglb1/igt@perf@gen12-mi-rpc.html

  * igt@perf_pmu@cpu-hotplug:
    - shard-hsw:          [INCOMPLETE][63] ([i915#1176] / [i915#61]) -> [PASS][64]
   [63]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-hsw5/igt@perf_pmu@cpu-hotplug.html
   [64]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-hsw7/igt@perf_pmu@cpu-hotplug.html

  * igt@prime_busy@hang-bsd2:
    - shard-iclb:         [SKIP][65] ([fdo#109276]) -> [PASS][66] +21 similar issues
   [65]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-iclb3/igt@prime_busy@hang-bsd2.html
   [66]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-iclb2/igt@prime_busy@hang-bsd2.html

  
#### Warnings ####

  * igt@gem_userptr_blits@sync-unmap-cycles:
    - shard-snb:          [DMESG-WARN][67] ([fdo#111870] / [i915#478]) -> [DMESG-WARN][68] ([fdo#110789] / [fdo#111870] / [i915#478])
   [67]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-snb6/igt@gem_userptr_blits@sync-unmap-cycles.html
   [68]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-snb1/igt@gem_userptr_blits@sync-unmap-cycles.html

  * igt@i915_pm_dc@dc6-psr:
    - shard-tglb:         [SKIP][69] ([i915#468]) -> [FAIL][70] ([i915#454])
   [69]: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_5450/shard-tglb2/igt@i915_pm_dc@dc6-psr.html
   [70]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/shard-tglb7/igt@i915_pm_dc@dc6-psr.html

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

  [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
  [fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
  [fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
  [fdo#110789]: https://bugs.freedesktop.org/show_bug.cgi?id=110789
  [fdo#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
  [fdo#111870]: https://bugs.freedesktop.org/show_bug.cgi?id=111870
  [fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
  [fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
  [fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
  [i915#1085]: https://gitlab.freedesktop.org/drm/intel/issues/1085
  [i915#1176]: https://gitlab.freedesktop.org/drm/intel/issues/1176
  [i915#1241]: https://gitlab.freedesktop.org/drm/intel/issues/1241
  [i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
  [i915#34]: https://gitlab.freedesktop.org/drm/intel/issues/34
  [i915#454]: https://gitlab.freedesktop.org/drm/intel/issues/454
  [i915#468]: https://gitlab.freedesktop.org/drm/intel/issues/468
  [i915#478]: https://gitlab.freedesktop.org/drm/intel/issues/478
  [i915#54]: https://gitlab.freedesktop.org/drm/intel/issues/54
  [i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
  [i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
  [i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
  [i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
  [i915#750]: https://gitlab.freedesktop.org/drm/intel/issues/750
  [i915#84]: https://gitlab.freedesktop.org/drm/intel/issues/84
  [i915#899]: https://gitlab.freedesktop.org/drm/intel/issues/899
  [i915#910]: https://gitlab.freedesktop.org/drm/intel/issues/910
  [i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96


Participating hosts (8 -> 8)
------------------------------

  No changes in participating hosts


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

  * CI: CI-20190529 -> None
  * IGT: IGT_5450 -> IGTPW_4184

  CI-20190529: 20190529
  CI_DRM_7963: e0d737598eb749378a5dc4ed3dfafc6f79d512cb @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_4184: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4184/index.html
  IGT_5450: dfba090e720ed4e043158887f1ba6a76059491e8 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools

== Logs ==

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