[igt-dev] [PATCH] igt_chameleon: Assert if there are no connected ports

[igt-dev] [PATCH] igt_chameleon: Assert if there are no connected ports

[Mark Yacoub]

[Why]
The tests are meant to run on devices that have a chameleon connected.
If autodiscovery finds no port, it means something is off and the DUT is
not behaving well.

[How]
Add an assert if no port is mapped.

Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
---
 lib/igt_chamelium.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/lib/igt_chamelium.c b/lib/igt_chamelium.c
index 79920de1..4e7a7a8f 100644
--- a/lib/igt_chamelium.c
+++ b/lib/igt_chamelium.c
@@ -2749,6 +2749,10 @@ unplug_port:
 	igt_debug("Auto-discovery took %fms and found %i connector(s)\n",
 		  (float)elapsed_ns / (1000 * 1000), chamelium->port_count);
 
+	igt_assert_f(
+		is_any_port_mapped,
+		"No port is mapped. We don't expect to have no connected connectors.\n");
+
 	return is_any_port_mapped;
 }
 
-- 
2.38.1.584.g0f3c55d4c2-goog

[igt-dev] ✗ Fi.CI.BAT: failure for igt_chameleon: Assert if there are no connected ports

[Patchwork]

[-- Attachment #1: Type: text/plain, Size: 7172 bytes --]

== Series Details ==

Series: igt_chameleon: Assert if there are no connected ports
URL   : https://patchwork.freedesktop.org/series/111493/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_12456 -> IGTPW_8176
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with IGTPW_8176 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in IGTPW_8176, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

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

Participating hosts (36 -> 37)
------------------------------

  Additional (2): fi-kbl-7567u fi-hsw-4770 
  Missing    (1): fi-ilk-m540 

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in IGTPW_8176:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@dmabuf:
    - fi-glk-dsi:         [PASS][1] -> [DMESG-FAIL][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/fi-glk-dsi/igt@i915_selftest@live@dmabuf.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-glk-dsi/igt@i915_selftest@live@dmabuf.html

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

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

### IGT changes ###

#### Issues hit ####

  * igt@gem_huc_copy@huc-copy:
    - fi-kbl-7567u:       NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-kbl-7567u/igt@gem_huc_copy@huc-copy.html

  * igt@gem_lmem_swapping@basic:
    - fi-kbl-7567u:       NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-kbl-7567u/igt@gem_lmem_swapping@basic.html

  * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy:
    - fi-hsw-4770:        NOTRUN -> [SKIP][5] ([fdo#109271]) +11 similar issues
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-hsw-4770/igt@kms_addfb_basic@addfb25-y-tiled-small-legacy.html

  * igt@kms_chamelium@common-hpd-after-suspend:
    - fi-ivb-3770:        NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827])
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-ivb-3770/igt@kms_chamelium@common-hpd-after-suspend.html

  * igt@kms_chamelium@dp-crc-fast:
    - fi-hsw-4770:        NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-hsw-4770/igt@kms_chamelium@dp-crc-fast.html

  * igt@kms_chamelium@dp-hpd-fast:
    - fi-kbl-7567u:       NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-kbl-7567u/igt@kms_chamelium@dp-hpd-fast.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
    - fi-bsw-kefka:       [PASS][9] -> [FAIL][10] ([i915#6298])
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions.html

  * igt@kms_psr@cursor_plane_move:
    - fi-kbl-7567u:       NOTRUN -> [SKIP][11] ([fdo#109271]) +30 similar issues
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-kbl-7567u/igt@kms_psr@cursor_plane_move.html

  * igt@kms_psr@sprite_plane_onoff:
    - fi-hsw-4770:        NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1072]) +3 similar issues
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html

  
#### Possible fixes ####

  * igt@fbdev@read:
    - {bat-rpls-2}:       [SKIP][13] ([i915#2582]) -> [PASS][14] +4 similar issues
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/bat-rpls-2/igt@fbdev@read.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/bat-rpls-2/igt@fbdev@read.html

  * igt@gem_exec_gttfill@basic:
    - fi-pnv-d510:        [FAIL][15] ([i915#7229]) -> [PASS][16]
   [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/fi-pnv-d510/igt@gem_exec_gttfill@basic.html
   [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-pnv-d510/igt@gem_exec_gttfill@basic.html
    - {bat-rpls-2}:       [DMESG-WARN][17] ([i915#6434]) -> [PASS][18] +1 similar issue
   [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/bat-rpls-2/igt@gem_exec_gttfill@basic.html
   [18]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/bat-rpls-2/igt@gem_exec_gttfill@basic.html

  * igt@i915_selftest@live@gt_lrc:
    - {bat-rpls-2}:       [INCOMPLETE][19] ([i915#4983]) -> [PASS][20]
   [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/bat-rpls-2/igt@i915_selftest@live@gt_lrc.html
   [20]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/bat-rpls-2/igt@i915_selftest@live@gt_lrc.html

  * igt@i915_selftest@live@hangcheck:
    - fi-ivb-3770:        [INCOMPLETE][21] ([i915#3303] / [i915#7122]) -> [PASS][22]
   [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12456/fi-ivb-3770/igt@i915_selftest@live@hangcheck.html
   [22]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/fi-ivb-3770/igt@i915_selftest@live@hangcheck.html

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

  [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
  [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
  [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
  [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
  [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
  [i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
  [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
  [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
  [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
  [i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
  [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
  [i915#6434]: https://gitlab.freedesktop.org/drm/intel/issues/6434
  [i915#6559]: https://gitlab.freedesktop.org/drm/intel/issues/6559
  [i915#7122]: https://gitlab.freedesktop.org/drm/intel/issues/7122
  [i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229


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

  * CI: CI-20190529 -> None
  * IGT: IGT_7076 -> IGTPW_8176

  CI-20190529: 20190529
  CI_DRM_12456: 7a3c5315507ed0f4a9b0aa07ce6df1b3d28ebc35 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGTPW_8176: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/index.html
  IGT_7076: 888725538e0d6bbb94bbbb1ac278d4afcbbbdad0 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git


Testlist changes
----------------

-igt@kms_async_flips@async-flip-with-page-flip-events-linear

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8176/index.html

[-- Attachment #2: Type: text/html, Size: 8539 bytes --]

Re: [igt-dev] [PATCH] igt_chameleon: Assert if there are no connected ports

[Petri Latvala]

On Wed, Nov 30, 2022 at 12:42:17PM -0500, Mark Yacoub wrote:
> [Why]
> The tests are meant to run on devices that have a chameleon connected.
> If autodiscovery finds no port, it means something is off and the DUT is
> not behaving well.
> 
> [How]
> Add an assert if no port is mapped.
> 
> Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
> ---
>  lib/igt_chamelium.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/lib/igt_chamelium.c b/lib/igt_chamelium.c
> index 79920de1..4e7a7a8f 100644
> --- a/lib/igt_chamelium.c
> +++ b/lib/igt_chamelium.c
> @@ -2749,6 +2749,10 @@ unplug_port:
>  	igt_debug("Auto-discovery took %fms and found %i connector(s)\n",
>  		  (float)elapsed_ns / (1000 * 1000), chamelium->port_count);
>  
> +	igt_assert_f(
> +		is_any_port_mapped,
> +		"No port is mapped. We don't expect to have no connected connectors.\n");
> +

If this situation (chamelium is configured but is not suitable for
testing) ever happens, in my opinion an igt_abort would be more
appropriate. Similar to the case where chamelium is configured but
cannot be reached. What do you think?


-- 
Petri Latvala

Re: [igt-dev] [PATCH] igt_chameleon: Assert if there are no connected ports

[Mark Yacoub]

On Thu, Dec 1, 2022 at 9:38 AM Petri Latvala <petri.latvala@intel.com> wrote:
>
> On Wed, Nov 30, 2022 at 12:42:17PM -0500, Mark Yacoub wrote:
> > [Why]
> > The tests are meant to run on devices that have a chameleon connected.
> > If autodiscovery finds no port, it means something is off and the DUT is
> > not behaving well.
> >
> > [How]
> > Add an assert if no port is mapped.
> >
> > Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
> > ---
> >  lib/igt_chamelium.c | 4 ++++
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/lib/igt_chamelium.c b/lib/igt_chamelium.c
> > index 79920de1..4e7a7a8f 100644
> > --- a/lib/igt_chamelium.c
> > +++ b/lib/igt_chamelium.c
> > @@ -2749,6 +2749,10 @@ unplug_port:
> >       igt_debug("Auto-discovery took %fms and found %i connector(s)\n",
> >                 (float)elapsed_ns / (1000 * 1000), chamelium->port_count);
> >
> > +     igt_assert_f(
> > +             is_any_port_mapped,
> > +             "No port is mapped. We don't expect to have no connected connectors.\n");
> > +
>
> If this situation (chamelium is configured but is not suitable for
> testing) ever happens, in my opinion an igt_abort would be more
> appropriate. Similar to the case where chamelium is configured but
> cannot be reached. What do you think?
>
So the case I saw is volteer failing to connect any of its ports
because of some bug it has that if it doesn't disconnect cleanly it
stops working without extra steps. I thought when we catch this, this
might be a good candidate for a real bug to file so it's a legit DUT
failure, hence the assert, rather than abort because test conditions
weren't met.
They're both good to me, so whatever you think is best.
>
> --
> Petri Latvala

Re: [igt-dev] [PATCH] igt_chameleon: Assert if there are no connected ports

[Petri Latvala]

On Thu, Dec 01, 2022 at 11:37:19AM -0500, Mark Yacoub wrote:
> On Thu, Dec 1, 2022 at 9:38 AM Petri Latvala <petri.latvala@intel.com> wrote:
> >
> > On Wed, Nov 30, 2022 at 12:42:17PM -0500, Mark Yacoub wrote:
> > > [Why]
> > > The tests are meant to run on devices that have a chameleon connected.
> > > If autodiscovery finds no port, it means something is off and the DUT is
> > > not behaving well.
> > >
> > > [How]
> > > Add an assert if no port is mapped.
> > >
> > > Signed-off-by: Mark Yacoub <markyacoub@chromium.org>
> > > ---
> > >  lib/igt_chamelium.c | 4 ++++
> > >  1 file changed, 4 insertions(+)
> > >
> > > diff --git a/lib/igt_chamelium.c b/lib/igt_chamelium.c
> > > index 79920de1..4e7a7a8f 100644
> > > --- a/lib/igt_chamelium.c
> > > +++ b/lib/igt_chamelium.c
> > > @@ -2749,6 +2749,10 @@ unplug_port:
> > >       igt_debug("Auto-discovery took %fms and found %i connector(s)\n",
> > >                 (float)elapsed_ns / (1000 * 1000), chamelium->port_count);
> > >
> > > +     igt_assert_f(
> > > +             is_any_port_mapped,
> > > +             "No port is mapped. We don't expect to have no connected connectors.\n");
> > > +
> >
> > If this situation (chamelium is configured but is not suitable for
> > testing) ever happens, in my opinion an igt_abort would be more
> > appropriate. Similar to the case where chamelium is configured but
> > cannot be reached. What do you think?
> >
> So the case I saw is volteer failing to connect any of its ports
> because of some bug it has that if it doesn't disconnect cleanly it
> stops working without extra steps. I thought when we catch this, this
> might be a good candidate for a real bug to file so it's a legit DUT
> failure, hence the assert, rather than abort because test conditions
> weren't met.
> They're both good to me, so whatever you think is best.

An abort result should be considered a bad result by CI systems. And a
DUT failure should look different from a kernel failure in my
opinion. Let's use abort here.


-- 
Petri Latvala