All of lore.kernel.org
 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: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-31 20:21 [PATCH v7 0/8] use DYNAMIC_DEBUG to implement DRM.debug Jim Cromie
2021-08-31 20:21 ` [Intel-gfx] " Jim Cromie
2021-08-31 20:21 ` [PATCH v7 1/8] dyndbg: add DEFINE_DYNAMIC_DEBUG_CATEGORIES and callbacks Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " Jim Cromie
2021-08-31 20:21 ` [PATCH v7 2/8] dyndbg: remove spaces in pr_debug "gvt: core:" etc prefixes Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " Jim Cromie
2021-08-31 20:21 ` [PATCH v7 3/8] i915/gvt: use DEFINE_DYNAMIC_DEBUG_CATEGORIES to create "gvt:core:" etc categories Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " Jim Cromie
2021-09-03 11:07   ` Tvrtko Ursulin
2021-09-03 19:22     ` jim.cromie
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-09-07 17:26               ` jim.cromie
2021-08-31 20:21 ` [PATCH v7 4/8] amdgpu: use DEFINE_DYNAMIC_DEBUG_CATEGORIES Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " Jim Cromie
2021-08-31 20:21 ` [PATCH v7 5/8] drm_print: add choice to use dynamic debug in drm-debug Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " Jim Cromie
2021-09-03 11:15   ` Tvrtko Ursulin
2021-09-03 21:57     ` jim.cromie
2021-09-03 21:57       ` jim.cromie
2021-09-06 10:20       ` Tvrtko Ursulin
2021-09-06 18:24         ` jim.cromie
2021-09-06 18:24           ` jim.cromie
2021-08-31 20:21 ` [PATCH v7 6/8] drm_print: instrument drm_debug_enabled Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " Jim Cromie
2021-09-05 18:50   ` jim.cromie
2021-09-05 18:50     ` [Intel-gfx] " jim.cromie
2021-09-05 18:50     ` jim.cromie
2021-08-31 20:21 ` [PATCH v7 7/8] amdgpu_ucode: reduce number of pr_debug calls Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " Jim Cromie
2021-08-31 20:21 ` [PATCH v7 8/8] nouveau: fold multiple DRM_DEBUG_DRIVERs together Jim Cromie
2021-08-31 20:21   ` [Intel-gfx] " 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.