[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Get pipe id following atomic guidelines (rev2)

[Peres, Martin]

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 at lists.freedesktop.org] On Behalf Of
>>>>> Rodrigo Vivi
>>>>> Sent: torstai 29. marraskuuta 2018 8.18
>>>>> To: Souza, Jose <jose.souza at intel.com>
>>>>> Cc: intel-gfx at 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 at i915_selftest@live_sanitycheck:
>>>>>>>     - fi-apl-guc:         PASS -> DMESG-WARN
>>>>>>>
>>>>>>>   * {igt at 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!

> 
> 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 Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.