Re: ✗ Fi.CI.BAT: failure for drm/i915/psr: Get pipe id following atomic guidelines (rev2)

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Mon, Dec 03, 2018 at 04:29:17AM -0800, Peres, Martin wrote:
> On 30/11/2018 19:27, Vivi, Rodrigo wrote:
> > On Fri, Nov 30, 2018 at 03:04:40PM +0200, Martin Peres wrote:
> >>
> >>
> >> On 29/11/2018 19:36, Rodrigo Vivi wrote:
> >>> On Wed, Nov 28, 2018 at 11:52:49PM -0800, Saarinen, Jani wrote:
> >>>> Hi, 
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Intel-gfx [mailto:intel-gfx-bounces@lists.freedesktop.org] On Behalf Of
> >>>>> Rodrigo Vivi
> >>>>> Sent: torstai 29. marraskuuta 2018 8.18
> >>>>> To: Souza, Jose <jose.souza@intel.com>
> >>>>> Cc: intel-gfx@lists.freedesktop.org
> >>>>> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Get pipe id
> >>>>> following atomic guidelines (rev2)
> >>>>>
> >>>>> On Wed, Nov 28, 2018 at 02:13:12PM -0800, Souza, Jose wrote:
> >>>>>> On Wed, 2018-11-28 at 21:02 +0000, Patchwork wrote:
> >>>>>>> == Series Details ==
> >>>>>>>
> >>>>>>> Series: drm/i915/psr: Get pipe id following atomic guidelines (rev2)
> >>>>>>> URL   : https://patchwork.freedesktop.org/series/53132/
> >>>>>>> State : failure
> >>>>>>>
> >>>>>>> == Summary ==
> >>>>>>>
> >>>>>>> CI Bug Log - changes from CI_DRM_5216 -> Patchwork_10934
> >>>>>>> ====================================================
> >>>>>>>
> >>>>>>> Summary
> >>>>>>> -------
> >>>>>>>
> >>>>>>>   **FAILURE**
> >>>>>>>
> >>>>>>>   Serious unknown changes coming with Patchwork_10934 absolutely
> >>>>>>> need to be
> >>>>>>>   verified manually.
> >>>>>>>
> >>>>>>>   If you think the reported changes have nothing to do with the
> >>>>>>> changes
> >>>>>>>   introduced in Patchwork_10934, please notify your bug team to
> >>>>>>> allow them
> >>>>>>>   to document this new failure mode, which will reduce false
> >>>>>>> positives in CI.
> >>>>>>>
> >>>>>>>   External URL:
> >>>>>>> https://patchwork.freedesktop.org/api/1.0/series/53132/revisions/2/m
> >>>>>>> box/
> >>>>>>>
> >>>>>>> Possible new issues
> >>>>>>> -------------------
> >>>>>>>
> >>>>>>>   Here are the unknown changes that may have been introduced in
> >>>>>>> Patchwork_10934:
> >>>>>>>
> >>>>>>> ### IGT changes ###
> >>>>>>>
> >>>>>>> #### Possible regressions ####
> >>>>>>>
> >>>>>>>   * igt@i915_selftest@live_sanitycheck:
> >>>>>>>     - fi-apl-guc:         PASS -> DMESG-WARN
> >>>>>>>
> >>>>>>>   * {igt@runner@aborted}:
> >>>>>>>     - fi-apl-guc:         NOTRUN -> FAIL
> >>>>>>
> >>>>>> Both are pretty much non related with display, what do you think
> >>>>>> Rodrigo? It is a merge blocker?
> >>>>>
> >>>>> I got addicted to see all green on CI. So I always prefer to trigger a retest. So
> >>>>> anyone following the link that is merged with the patch doens't have to
> >>>>> understand and analyze why it was merged with BAT failure.
> >>>>>
> >>>>> I just triggered the re-test for this patch.
> >>>> Martin, Arek, fyi, not preferred? 
> >>>
> >>> Yes, I'd like to hear their opinion.
> >>>
> >>> On this case a simple BAT would be enough because we don't have PSR monitors
> >>> on shrd ones.
> >>> However most of the times trigger the retest is unavoidable because we need
> >>> to make it to pass BAT and go for the full run.
> >>>
> >>> Besides the green-report-link reason I exposed above.
> >>
> >> I agree that we should only push stuff when CI is green.
> >>
> >> However, using the re-try button is the wrong way as it requires more
> >> machine time, and it may hide low-probably issues introduced by the patch.
> >>
> >> Instead, we should file/edit bugs and then ask cibuglog to re-send the
> >> report. I have been doing this ofr a couple of people already, but we
> >> need to advertise this more!
> > 
> > This makes total sense for me. But I wonder if we don't need at least
> > one re-run.
> > 
> > My feeling is that if we tell people to file bugs and regenerate
> > reports they might just end up accidentally ignoring regressions that
> > was caused by their own patches.
> 
> Yeah, I get your point... but machine time is also problematic...
> 
> In most cases, it is just that I need to extend a filter, which does not
> warrant a new run.
> 
> If something is new or odd, we could use a re-run ;)
> 
> In any case, if I file the bug and we land a regression, it will not
> affect CI. So that's just an additional workload for bug tracking and
> fixing. But we'll have a documented trail leading back to the developer,
> so we can assign him more easily!

I was wondering here if instead a instruction we could create
a button on patchwork besides "test again"... "report cibuglog".
with instructions right below to only hit "test again" if it is really
odd?

possible? or the report cibuglog is really more manual?

> 
> > 
> > But anyway is there a doc with step-by-step instructions anywhere that
> > we could learn from and start doing this without overwhelming a single
> > person?
> 
> Not yet. I need to send this information... and you are absolutely right
> on the bottleneck here: I do not scale ... and I do not have time to
> make my work less labor-intensive because I don't have time to work on
> it. Nice isn't it?
> 
> In any case, the current process is just to forward me the result email,
> then I will look at the filing and re-report.
> 
> Martin
> 
> > 
> > Thanks a lot!
> 
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx