intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: "Gupta, Anshuman" <anshuman.gupta@intel.com>
To: "Latvala, Petri" <petri.latvala@intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: "jim.cromie@gmail.com" <jim.cromie@gmail.com>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	"Bhatt, Jigar" <jigar.bhatt@intel.com>
Subject: Re: [Intel-gfx]  ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to implement DRM.debug (rev2)
Date: Tue, 7 Sep 2021 04:13:56 +0000	[thread overview]
Message-ID: <fc0ff49e5e6848f3ba80a5690779f651@intel.com> (raw)
In-Reply-To: <YTX6t3PtgFxD7Ers@platvala-desk.ger.corp.intel.com>



> -----Original Message-----
> From: Latvala, Petri <petri.latvala@intel.com>
> Sent: Monday, September 6, 2021 4:56 PM
> To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
> Cc: jim.cromie@gmail.com; Intel Graphics Development <intel-
> gfx@lists.freedesktop.org>; Bhatt, Jigar <jigar.bhatt@intel.com>; Gupta,
> Anshuman <anshuman.gupta@intel.com>
> Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for use DYNAMIC_DEBUG to
> implement DRM.debug (rev2)
> 
> On Mon, Sep 06, 2021 at 11:04:13AM +0100, Tvrtko Ursulin wrote:
> >
> > On 03/09/2021 14:01, Petri Latvala wrote:
> > > On Fri, Sep 03, 2021 at 12:29:51PM +0100, Tvrtko Ursulin wrote:
> > > >
> > > > On 03/09/2021 01:31, jim.cromie@gmail.com wrote:
> > > > >
> > > > >
> > > > > On Tue, Aug 31, 2021 at 5:38 PM Patchwork
> > > > > <patchwork@emeril.freedesktop.org
> > > > > <mailto:patchwork@emeril.freedesktop.org>> wrote:
> > > > >
> > > > >      __
> > > > >      *Patch Details*
> > > > >      *Series:*	use DYNAMIC_DEBUG to implement DRM.debug (rev2)
> > > > >      *URL:*	https://patchwork.freedesktop.org/series/93914/
> > > > >      <https://patchwork.freedesktop.org/series/93914/>
> > > > >      *State:*	failure
> > > > >      *Details:*
> > > > >      https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/index.html
> > > > >
> > > > > <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/index.
> > > > > html>
> > > > >
> > > > >
> > > > >        CI Bug Log - changes from CI_DRM_10541_full ->
> > > > > Patchwork_20931_full
> > > > >
> > > > >
> > > > >          Summary
> > > > >
> > > > >      *FAILURE*
> > > > >
> > > > >      Serious unknown changes coming with Patchwork_20931_full
> absolutely
> > > > >      need to be
> > > > >      verified manually.
> > > > >
> > > > >      If you think the reported changes have nothing to do with the changes
> > > > >      introduced in Patchwork_20931_full, please notify your bug team to
> > > > >      allow them
> > > > >      to document this new failure mode, which will reduce false positives
> > > > >      in CI.
> > > > >
> > > > >
> > > > > hi Team !
> > > > >
> > > > > I think I need a bit of orientation.
> > > > >
> > > > >
> > > > >          Possible new issues
> > > > >
> > > > >      Here are the unknown changes that may have been introduced in
> > > > >      Patchwork_20931_full:
> > > > >
> > > > >
> > > > >            IGT changes
> > > > >
> > > > >
> > > > >              Possible regressions
> > > > >
> > > > >        * igt@gem_exec_schedule@u-submit-golden-slice@vcs0:
> > > > >            o shard-skl: NOTRUN -> INCOMPLETE
> > > > >
> > > > > <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-
> > > > > skl10/igt@gem_exec_schedule@u-submit-golden-slice@vcs0.html>
> > > > >
> > > > >
> > > > >              Warnings
> > > > >
> > > > >        * igt@i915_pm_dc@dc9-dpms:
> > > > >            o shard-skl: SKIP
> > > > >              <https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10541/shard-
> skl6/igt@i915_pm_dc@dc9-dpms.html>
> > > > >              ([fdo#109271]) -> FAIL
I915_pm_dc test failures are not related to your series , probably  this failure can be ignored.
Br,
Anshuman Gupta.
> > > > >
> > > > > <https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20931/shard-
> > > > > skl8/igt@i915_pm_dc@dc9-dpms.html>
> > > > >
> > > > >
> > > > >
> > > > > Im assuming the FAIL is the sticking point,
> > > >
> > > > Both INCOMPLETE and FAIL will cause a failure to be declared, but in this
> case it looks to me this series is not at fault.
> > > >
> > > > 1)
> > > >
> > > > The gem_exec_schedule failure looks like a test runner timeout issue (and
> apparently test does not handle well running the the fence timeout enabled).
> > > >
> > > > @Petri - does the below look like IGT runner running our of time
> > > > budget for the test run? Would it log
> > > >
> > > > [1051.943629] [114/138] ( 11s left) gem_exec_schedule
> > > > (u-submit-golden-slice) Starting subtest: u-submit-golden-slice
> > > > Starting dynamic subtest: rcs0 Dynamic subtest rcs0: SUCCESS
> > > > (80.175s) Starting dynamic subtest: bcs0 Dynamic subtest bcs0:
> > > > SUCCESS (80.195s) Starting dynamic subtest: vcs0 Dynamic subtest
> > > > vcs0: SUCCESS (80.243s) Starting dynamic subtest: vecs0
> > > >
> > > > Interesting part is that according to dmesg it never got to the vecs0
> dynamic subtest - any idea what happened there?
> > >
> > > Yep, we ran out of time. We still had 11 seconds left to execute
> > > something but then that test took centuries.
> >
> > Okay at least that's explained then.
> >
> > Perhaps could make that act of termination logged in igt_runner log?
> 
> We do log everything we can, but unfortunately this was such an extreme case
> that it hit the timeout that just cuts off AC power.
> 
> run.log has this act logged.
> 
> >
> > Also, any explanation on why dmesg and igt_runner log disagree on how
> > far the test progressed (in terms of which subtest was active when
> > things ended)?
> >
> 
> Looks like a race condition with the above mentioned AC cutoff. The test printed
> that vcs0 is finished and vecs0 starts, that info was printed to igt_runner's
> stdout, but the write() to the test logs didn't get called before cutoff.
> 
> 
> --
> Petri Latvala
> 
> 
> > Regards,
> >
> > Tvrtko
> >
> >
> > >
> > >
> > > >
> > > > 2)
> > > >
> > > > I915_pm_dc I'd say you just gotten unlucky that test went from always
> skipping on SKL to trying to run it and then it failed. But I don't know enough
> about the test to tell you why. Adding Jigar and Anshuman as test author and
> reviewer who might be able to shed some light here.
> > > >
> > > > Regards,
> > > >
> > > > Tvrtko
> > > >
> > > > > I found code that seemed to be relevant
> > > > >
> > > > > [jimc@frodo igt-ci-tags.git]$ git remote -v
> > > > > origin https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git
> > > > > <https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git> (fetch)
> > > > > origin https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git
> > > > > <https://gitlab.freedesktop.org/gfx-ci/igt-ci-tags.git> (push)
> > > > >
> > > > > I built it, got an error, threw that to google,
> > > > > found a patch on i-g-t from
> > > > > commit 1ff3e5ae99ceb66d2926d58635d0379ce971065a (HEAD ->
> master)
> > > > > Author: Lyude Paul <lyude@redhat.com <mailto:lyude@redhat.com>>
> > > > > Date:   Mon Apr 15 14:57:23 2019 -0400
> > > > >
> > > > > and applied it
> > > > > it fixed the one problem
> > > > >
> > > > > then I looked at previous head
> > > > >
> > > > > commit f052e49a43cc9704ea5f240df15dd9d3dfed68ab (origin/master,
> origin/HEAD)
> > > > > Author: Simon Ser <simon.ser@intel.com
> <mailto:simon.ser@intel.com>>
> > > > > Date:   Wed Apr 24 19:15:26 2019 +0300
> > > > >
> > > > > It sure seems that tree is stale.
> > >
> > > That tree's master ref does not get updated. It's only for storing tags.
> > >
> > > That test result comparison was too long to fit into patchwork so the
> > > build information at the bottom is missing, but the BAT results have
> > > it:
> > >
> > > IGT_6193: 080869f804cb86b25a38889e5ce9a870571cd8c4 @
> https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
> > >
> > >
> > >

      reply	other threads:[~2021-09-07  4:14 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-31 20:21 [Intel-gfx] [PATCH v7 0/8] use DYNAMIC_DEBUG to implement DRM.debug Jim Cromie
2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 1/8] dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks Jim Cromie
2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 2/8] dyndbg: remove spaces in pr_debug "gvt: core:" etc prefixes Jim Cromie
2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories Jim Cromie
2021-09-03 11:07   ` Tvrtko Ursulin
2021-09-03 19:22     ` jim.cromie
2021-09-06 12:26       ` Tvrtko Ursulin
2021-09-06 17:41         ` jim.cromie
2021-09-07 15:14           ` Tvrtko Ursulin
2021-09-07 17:26             ` jim.cromie
2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 4/8] amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES Jim Cromie
2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 5/8] drm_print: add choice to use dynamic debug in drm-debug Jim Cromie
2021-09-03 11:15   ` Tvrtko Ursulin
2021-09-03 21:57     ` jim.cromie
2021-09-06 10:20       ` Tvrtko Ursulin
2021-09-06 18:24         ` jim.cromie
2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 6/8] drm_print: instrument drm_debug_enabled Jim Cromie
2021-09-05 18:50   ` jim.cromie
2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 7/8] amdgpu_ucode: reduce number of pr_debug calls Jim Cromie
2021-08-31 20:21 ` [Intel-gfx] [PATCH v7 8/8] nouveau: fold multiple DRM_DEBUG_DRIVERs together Jim Cromie
2021-08-31 21:33 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for use DYNAMIC_DEBUG to implement DRM.debug (rev2) Patchwork
2021-08-31 21:37 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2021-08-31 22:01 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2021-08-31 23:38 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-09-03  0:31   ` jim.cromie
2021-09-03 11:29     ` Tvrtko Ursulin
2021-09-03 13:01       ` Petri Latvala
2021-09-05 17:35         ` jim.cromie
2021-09-06 10:14           ` Tvrtko Ursulin
2021-09-06 10:04         ` Tvrtko Ursulin
2021-09-06 11:25           ` Petri Latvala
2021-09-07  4:13             ` Gupta, Anshuman [this message]

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=fc0ff49e5e6848f3ba80a5690779f651@intel.com \
    --to=anshuman.gupta@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jigar.bhatt@intel.com \
    --cc=jim.cromie@gmail.com \
    --cc=petri.latvala@intel.com \
    --cc=tvrtko.ursulin@linux.intel.com \
    /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;
as well as URLs for NNTP newsgroup(s).