Igt-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Harish Chegondi <harish.chegondi@intel.com>
Cc: <igt-dev@lists.freedesktop.org>
Subject: Re: [PATCH i-g-t 1/1] tests/intel/xe_eu_stall: Do not check for presence of data on simulation
Date: Tue, 13 May 2025 15:16:14 -0700	[thread overview]
Message-ID: <87wmak6tsh.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <aCOyRTu5s_Is5etp@intel.com>

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

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?

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

Better to investigate this a little bit more I think.

Thanks.
--
Ashutosh


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

  reply	other threads:[~2025-05-13 22:16 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-13  3:07 [PATCH i-g-t 1/1] tests/intel/xe_eu_stall: Do not check for presence of data on simulation Harish Chegondi
2025-05-13  4:02 ` ✓ Xe.CI.BAT: success for series starting with [i-g-t,1/1] " Patchwork
2025-05-13  4:17 ` ✓ i915.CI.BAT: " Patchwork
2025-05-13  5:01 ` ✗ Xe.CI.Full: failure " Patchwork
2025-05-13  7:04 ` ✗ i915.CI.Full: " Patchwork
2025-05-13 16:43 ` [PATCH i-g-t 1/1] " Dixit, Ashutosh
2025-05-13 20:57   ` Harish Chegondi
2025-05-13 22:16     ` Dixit, Ashutosh [this message]
2025-05-14  6:03       ` Dixit, Ashutosh
2025-05-20  4:09         ` Harish Chegondi
2025-05-21 21:30           ` Dixit, Ashutosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87wmak6tsh.wl-ashutosh.dixit@intel.com \
    --to=ashutosh.dixit@intel.com \
    --cc=harish.chegondi@intel.com \
    --cc=igt-dev@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox