What	Removed	Added
QA Contact	intel-gfx-bugs@lists.freedesktop.org
Assignee	intel-gfx-bugs@lists.freedesktop.org	dri-devel@lists.freedesktop.org
Component	DRM/Intel	IGT

What

Removed

Added

QA Contact

intel-gfx-bugs@lists.freedesktop.org

Assignee

intel-gfx-bugs@lists.freedesktop.org

dri-devel@lists.freedesktop.org

Component

DRM/Intel

IGT

The CI Bug Log issue associated to this bug has been updated. ### New filters associated * CHAMELIUM: igt@kms_chamelium@hdmi-crc-fast - fail - Chamelium RPC= call failed: RPC failed at server. <type 'exceptions.ZeroDivisionError'>:integer division or= =20 - https://intel-gfx-ci.01.org= /tree/drm-tip/CI_DRM_5629/fi-kbl-7500u/igt@kms_chamelium@hdmi-crc-f= ast.html

Commen= t # 3 on bug 10967= 9 from Stuart Summers

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 ->
_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.

Sent that previous comment a little too quickly... It looks li= ke we aren't actually sending those 0's in the first place, in addition to my off-by-one (given we are taking 0 - 1, not 0) miss: (w && h) ? "(iiiiii)" : "(iinnnn)", >>From chameleond, this will autofill x, y, width, and height based on the current resolution. Maybe the resolution was misconfigured? Or perhaps ther= e's an issue in the chamelium FPGA? I still think it would be interesting here to get the chameleond log (see request here: https://gitlab.freedesktop.org/gfx-ci/i915-infra/issues/29 + = the recent patch I posted to igt). There is quite a bit of state logging in chameleond with that patch run locally with --d. The only other thing I see interesting in the logs is this, just before the error: (kms_chamelium:2877) igt_chamelium-DEBUG: Chamelium needs FSM, handling I don't see that when I run locally. Maybe we're getting a spurious hotplug event while trying to capture video? Or maybe the video capture is taking to long and/or hung for some reason, causing the hotplug to timeout?

What	Removed	Added
Assignee	dri-devel@lists.freedesktop.org	stuart.summers@intel.com

What

Removed

Added

Assignee

dri-devel@lists.freedesktop.org

stuart.summers@intel.com