From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 21E28C3ABC5 for ; Wed, 14 May 2025 06:03:59 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id CA74E10E19B; Wed, 14 May 2025 06:03:58 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="hRU1G1q7"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.12]) by gabe.freedesktop.org (Postfix) with ESMTPS id D30BE10E1DC for ; Wed, 14 May 2025 06:03:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1747202635; x=1778738635; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=Ci5UTG4qNgq5jKM6luv9lbPSlth3d5pbE5y1HveXdU8=; b=hRU1G1q7oUwl9YI28HGJt3FM2xdaaNcviBkBmS7fpvwCKDAWOGiUxllk moLsoi9VyHluOlsAJmxaXaHJ78txhtMJZlK1K0bnZP5VjhXZTbQKzychZ XfX00qncarBUg9kBu0fr6HiYgB+gobgHXhO/NfU0GSN3pGPhygWT/Tyl9 6HPSG/DdhF8sCmaSty3Om6GAy3f8hYZwnOjSxWZrFmJv5M5riO+Rot9mT M3s3p6SV/RcLTlLNXgI1g+K7znI6s0MnqKT+thFaL5UP+YaRgDi2Bz086 /kxmgUe+LijWvsrfy16yNJzcdzYuLL57Kqeewt/Rc/Sgezi5Xyo0oPPMt A==; X-CSE-ConnectionGUID: ranrDqciS+mJTculd2cnHA== X-CSE-MsgGUID: Pay4vZ3NSGi65FmKVia+ZQ== X-IronPort-AV: E=McAfee;i="6700,10204,11432"; a="52887035" X-IronPort-AV: E=Sophos;i="6.15,287,1739865600"; d="scan'208";a="52887035" Received: from orviesa003.jf.intel.com ([10.64.159.143]) by fmvoesa106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2025 23:03:54 -0700 X-CSE-ConnectionGUID: aF7jMmGPTKSdDIqey4qTWA== X-CSE-MsgGUID: 15AXaaSfQ+GM6q5V1gc3hw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,287,1739865600"; d="scan'208";a="142696283" Received: from hhitiham-mobl.amr.corp.intel.com (HELO adixit-MOBL3.intel.com) ([10.125.89.146]) by ORVIESA003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 May 2025 23:03:53 -0700 Date: Tue, 13 May 2025 23:03:53 -0700 Message-ID: <87v7q37mpi.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Harish Chegondi Cc: Subject: Re: [PATCH i-g-t 1/1] tests/intel/xe_eu_stall: Do not check for presence of data on simulation In-Reply-To: <87wmak6tsh.wl-ashutosh.dixit@intel.com> References: <7480b4adc93d3606d60d718d269c92791c22df68.1747105491.git.harish.chegondi@intel.com> <85a57glavf.wl-ashutosh.dixit@intel.com> <87wmak6tsh.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/29.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: igt-dev@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development mailing list for IGT GPU Tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: igt-dev-bounces@lists.freedesktop.org Sender: "igt-dev" 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 > > > > --- > > > > 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. > > 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 > > > >