[PATCH i-g-t 1/1] tests/intel/xe_eu_stall: Do not check for presence of data on simulation

[Harish Chegondi]

On Tue, May 13, 2025 at 11:03:53PM -0700, Dixit, Ashutosh wrote:
> On Tue, 13 May 2025 15:16:14 -0700, Dixit, Ashutosh wrote:
> >
> > On Tue, 13 May 2025 13:57:41 -0700, Harish Chegondi wrote:
> > >
> > > On Tue, May 13, 2025 at 09:43:32AM -0700, Dixit, Ashutosh wrote:
> > > > On Mon, 12 May 2025 20:07:38 -0700, Harish Chegondi wrote:
> > > > >
> > > > > Some simulation models may not have full EU stall sampling support.
> > > > >
> > > > > Signed-off-by: Harish Chegondi <harish.chegondi at intel.com>
> > > > > ---
> > > > >  tests/intel/xe_eu_stall.c | 4 +++-
> > > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/tests/intel/xe_eu_stall.c b/tests/intel/xe_eu_stall.c
> > > > > index 411c30871..bdfa0fc4b 100644
> > > > > --- a/tests/intel/xe_eu_stall.c
> > > > > +++ b/tests/intel/xe_eu_stall.c
> > > > > @@ -586,7 +586,6 @@ enable:
> > > > >
> > > > >	ret = wait_child(&work_load);
> > > > >	igt_assert_f(ret == 0, "waitpid() - ret: %d, errno: %d\n", ret, errno);
> > > > > -	igt_assert_f(num_samples, "No EU stalls detected during the workload\n");
> > > > >
> > > > >	do_ioctl(stream_fd, DRM_XE_OBSERVATION_IOCTL_DISABLE, 0);
> > > > >	if (--iter)
> > > > > @@ -594,6 +593,9 @@ enable:
> > > > >
> > > > >	close(stream_fd);
> > > > >	free(buf);
> > > > > +
> > > > > +	if (!igt_run_in_simulation())
> > > > > +		igt_assert_f(num_samples, "No EU stalls detected during the workload\n");
> > > >
> > > > Do we really want to move this here? Wasn't the earlier location better
> > > > since it checked num_samples for every iteration, whereas now we'd check it
> > > > only for the last iteration?
> > > Hi Ashutosh,
> > >
> > > Initially I didn't move. When testing I noticed that if there is no
> > > data, the assert triggers and the following close() and free() are not
> > > called. When the next sub-test gets executed, it returns EBUSY as the
> > > stream is not closed in the previous test. So, I moved this check here.
> > > Anyhow the data from the first iteration is checked in the blocking-read
> > > and non-blocking-read subtests where there is only one iteration.
> >
> > Hmm, the problem is, it's making the code look weird now. Also, if the
> > process dies in an assert, the fd should get closed when the process
> > died.
> 
> Actually, not sure about this, because it is not a fd created by the
> process but an anon fd returned by the open ioctl, so not sure if it gets
> closed. I have seen similar EBUSY's happening in OA tests too when things
> fail. Anyway, take a quick look and see what's happening, if release() is
> getting called or not.
> 
> If EBUSY's are ok, we can add the sim check in the previous place.
Hi Ashutosh,

I have put prints in the driver release() function and ran several
tests. I see that if the test doesn't explicitly close the fd, the fd
gets closed at the end of the test. If no subtest is specified to run,
all sub-tests are run one after another. If one subtest opens an fd but
doesn't close it (due to an assert before close()), it will be closed
only after all subtests have run. Buf if only one subtest is run and the
fd isn't closed in the test due to an assert, the fd gets closed and
release() called at the end of the subtest.

Since I moved the assert() after close(), if the assert gets triggered,
it doesn't affect the next subtest as the close() was called. If I don't
move the assert() after close(), an assert will not close fd and the
next subtest, if it calls open to get another fd, the driver returns
-EBUSY as an earlier session was not closed.
> 
> >
> > Or is there a delay between the process dying and fd getting closed? And
> > the next process is trying to open the fd before the previous process
> > closed the fd? Where did you see the EBUSY issue, is it happening in CI? Or
> > what are you executing to reproduce the EBUSY issue?
If a subtest doesn't call close() due to an assert() and the next
subtest calls open(), the driver while initializing notices that there
is an open session and returns -EBUSY.
> >
> > Can you please add a print in the eu stall release fops and see if
> > release() is not getting called when the process dies (put an artificial
> > assert in igt if needed).
Please see above. I can confirm that if the test doesn't close the fd,
the fd is getting closed at the end of the test.
> >
> > Better to investigate this a little bit more I think.
> >
> > Thanks.
> > --
> > Ashutosh
> >
Thank you
Harish.

> >
> > > >
> > > >
> > > > >  }
> > > > >
> > > > >  static int opt_handler(int opt, int opt_index, void *data)
> > > > > --
> > > > > 2.48.1
> > > > >