Re: ✗ Xe.CI.FULL: failure for tests/intel/xe_oa: Add test to ensure entire report has landed (rev2)

["Dixit, Ashutosh" <ashutosh.dixit@intel.com>]

On Tue, 01 Sep 2026 16:06:15 -0700, Umesh Nerlige Ramappa wrote:
>
> On Wed, Aug 26, 2026 at 06:53:22AM +0000, Patchwork wrote:
> >   Patch Details
> >
> >   Series:  tests/intel/xe_oa: Add test to ensure entire report has landed
> > (rev2)                                                              URL:
> > https://patchwork.freedesktop.org/series/172599/
> > State:   failure
> > Details: https://intel-gfx-ci.01.org/tree/intel-xe/IGTPW_15735/index.html
> >        CI Bug Log - changes from XEIGT_9074_FULL -> XEIGTPW_15735_FULL
> >
> > Summary
> >
> >   FAILURE
> >
> >   Serious unknown changes coming with XEIGTPW_15735_FULL absolutely need to
> >   be
> >   verified manually.
> >
> >   If you think the reported changes have nothing to do with the changes
> >   introduced in XEIGTPW_15735_FULL, please notify your bug team
> >   (I915-ci-infra@lists.freedesktop.org) to allow them
> >   to document this new failure mode, which will reduce false positives in
> >   CI.
> >
> > Participating hosts (2 -> 2)
> >
> >   No changes in participating hosts
> >
> > Possible new issues
> >
> >   Here are the unknown changes that may have been introduced in
> >   XEIGTPW_15735_FULL:
> >
> >  IGT changes
> >
> >    Possible regressions
> >
> >     * igt@kms_cursor_edge_walk@256x256-right-edge@pipe-a-dp-2:
> >
> >          * shard-bmg: PASS -> ABORT
> >     * {igt@xe_oa@non-zero-reports} (NEW):
> >
> >          * shard-lnl: NOTRUN -> FAIL +1 other test fail
> >
> > New tests
> >
> >   New tests have been introduced between XEIGT_9074_FULL and
> >   XEIGTPW_15735_FULL:
> >
> >  New IGT tests (2)
> >
> >     * igt@xe_oa@non-zero-reports:
> >
> >          * Statuses : 1 fail(s)
> >          * Exec time: [0.49] s
> >     * igt@xe_oa@non-zero-reports@oag-0:
> >
> >          * Statuses : 1 fail(s)
> >          * Exec time: [0.46] s
>
> Looks like the failure here in LNL is a different (new) issue. The oa
> config does not seem to have applied correctly in this case, so the report
> is using bad PES values. The test may have to wait on a fence for the
> config to be applied fully.

Hmm, if we don't specify syncs in the input properties, the kernel will
itself wait on the fence for OA config to be applied. We aren't even sure
if PES config needs the 500 microsecond NOA wait delay. Or, if PES config
is not being applied correctly, we could try to increase that 500 us delay
and check if that makes a difference.

Thanks.
--
Ashutosh