From mboxrd@z Thu Jan  1 00:00:00 1970
From: bugzilla-daemon@freedesktop.org
Subject: [Bug 109679] [CI][BAT] CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast -
 fail - Chamelium RPC call failed: RPC failed at server.  <type
 'exceptions.ZeroDivisionError'>:integer division or
Date: Tue, 19 Feb 2019 18:10:53 +0000
Message-ID: <bug-109679-502-uvurWesWI7@http.bugs.freedesktop.org/>
References: <bug-109679-502@http.bugs.freedesktop.org/>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0134161939=="
Return-path: <dri-devel-bounces@lists.freedesktop.org>
Received: from culpepper.freedesktop.org (culpepper.freedesktop.org
 [IPv6:2610:10:20:722:a800:ff:fe98:4b55])
 by gabe.freedesktop.org (Postfix) with ESMTP id A627C8932B
 for <dri-devel@lists.freedesktop.org>; Tue, 19 Feb 2019 18:10:53 +0000 (UTC)
In-Reply-To: <bug-109679-502@http.bugs.freedesktop.org/>
List-Unsubscribe: <https://lists.freedesktop.org/mailman/options/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <https://lists.freedesktop.org/archives/dri-devel>
List-Post: <mailto:dri-devel@lists.freedesktop.org>
List-Help: <mailto:dri-devel-request@lists.freedesktop.org?subject=help>
List-Subscribe: <https://lists.freedesktop.org/mailman/listinfo/dri-devel>,
 <mailto:dri-devel-request@lists.freedesktop.org?subject=subscribe>
Errors-To: dri-devel-bounces@lists.freedesktop.org
Sender: "dri-devel" <dri-devel-bounces@lists.freedesktop.org>
To: dri-devel@lists.freedesktop.org
List-Id: dri-devel@lists.freedesktop.org


--===============0134161939==
Content-Type: multipart/alternative; boundary="15505998530.EFac.28639"
Content-Transfer-Encoding: 7bit


--15505998530.EFac.28639
Date: Tue, 19 Feb 2019 18:10:53 +0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated

https://bugs.freedesktop.org/show_bug.cgi?id=3D109679

--- Comment #3 from Stuart Summers <stuart.summers@intel.com> ---
Agree this looks like an issue in IGT or possibly in the chameleond daemon.=
 At
a quick glance, there aren't a whole lot of places in the CaptureVideo path
that might trigger this exception in chameleond. It does look feasible that=
 if
we were to pass a 0 for width and height, we could potentially get a
div-by-zero exception when chameleond prepares the video output:
CaptureVideo ->
_PrepareCapturingVideo/_captured_params['max_frame_limit']/flow_manager.Get=
MaxFrameLimit
-> input_flow.GetMaxFrameLimit -> frame_manager.GetMaxFrameLimit ->
field_manager.GetMaxFieldLimit -> VideoDumper.GetMaxFieldLimit:
  def GetMaxFieldLimit(cls, width, height):=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
    """Returns of the maximal number of fields which can be dumped."""=20
    BYTE_PER_PIXEL =3D 3=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20
    PAGE_SIZE =3D 4096=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
    field_size =3D width * height * BYTE_PER_PIXEL=20=20=20
    field_size =3D ((field_size - 1) / PAGE_SIZE + 1) * PAGE_SIZE
    return cls._DUMP_BUFFER_SIZE / field_size

That said, running this myself locally does not result in the failure of th=
is
sighting, and from kms_chamelium.c, during the CRC check, we are passing 0 =
for
width and height:
  chamelium_capture(data->chamelium, port, 0, 0, 0, 0, count);

So I'd expect this to fail all the time if the issue were in the Python cal=
l I
indicated above.

And I'd also expect for CI to have seen this already if that were the case,
given this code has been present for some time.

--=20
You are receiving this mail because:
You are the assignee for the bug.=

--15505998530.EFac.28639
Date: Tue, 19 Feb 2019 18:10:53 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://bugs.freedesktop.org/
Auto-Submitted: auto-generated

<html>
    <head>
      <base href=3D"https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class=3D"bz_bug_link=20
          bz_status_NEW "
   title=3D"NEW - [CI][BAT] CHAMELIUM: igt&#64;kms_chamelium&#64;hdmi-crc-f=
ast - fail - Chamelium RPC call failed: RPC failed at server. &lt;type 'exc=
eptions.ZeroDivisionError'&gt;:integer division or"
   href=3D"https://bugs.freedesktop.org/show_bug.cgi?id=3D109679#c3">Commen=
t # 3</a>
              on <a class=3D"bz_bug_link=20
          bz_status_NEW "
   title=3D"NEW - [CI][BAT] CHAMELIUM: igt&#64;kms_chamelium&#64;hdmi-crc-f=
ast - fail - Chamelium RPC call failed: RPC failed at server. &lt;type 'exc=
eptions.ZeroDivisionError'&gt;:integer division or"
   href=3D"https://bugs.freedesktop.org/show_bug.cgi?id=3D109679">bug 10967=
9</a>
              from <span class=3D"vcard"><a class=3D"email" href=3D"mailto:=
stuart.summers&#64;intel.com" title=3D"Stuart Summers &lt;stuart.summers&#6=
4;intel.com&gt;"> <span class=3D"fn">Stuart Summers</span></a>
</span></b>
        <pre>Agree this looks like an issue in IGT or possibly in the chame=
leond daemon. At
a quick glance, there aren't a whole lot of places in the CaptureVideo path
that might trigger this exception in chameleond. It does look feasible that=
 if
we were to pass a 0 for width and height, we could potentially get a
div-by-zero exception when chameleond prepares the video output:
CaptureVideo -&gt;
_PrepareCapturingVideo/_captured_params['max_frame_limit']/flow_manager.Get=
MaxFrameLimit
-&gt; input_flow.GetMaxFrameLimit -&gt; frame_manager.GetMaxFrameLimit -&gt;
field_manager.GetMaxFieldLimit -&gt; VideoDumper.GetMaxFieldLimit:
  def GetMaxFieldLimit(cls, width, height):=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
    &quot;&quot;&quot;Returns of the maximal number of fields which can be =
dumped.&quot;&quot;&quot;=20
    BYTE_PER_PIXEL =3D 3=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20
    PAGE_SIZE =3D 4096=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
    field_size =3D width * height * BYTE_PER_PIXEL=20=20=20
    field_size =3D ((field_size - 1) / PAGE_SIZE + 1) * PAGE_SIZE
    return cls._DUMP_BUFFER_SIZE / field_size

That said, running this myself locally does not result in the failure of th=
is
sighting, and from kms_chamelium.c, during the CRC check, we are passing 0 =
for
width and height:
  chamelium_capture(data-&gt;chamelium, port, 0, 0, 0, 0, count);

So I'd expect this to fail all the time if the issue were in the Python cal=
l I
indicated above.

And I'd also expect for CI to have seen this already if that were the case,
given this code has been present for some time.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>=

--15505998530.EFac.28639--

--===============0134161939==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs
IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz
dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVs

--===============0134161939==--