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

Tue Dec 4 11:25:40 UTC 2018

On 03/12/2018 22:55, Vivi, Rodrigo wrote:
> 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 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!
> 
> 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?

Bug filing is manual. Once filed, the matching is automatic.

I have plans to automate bug filings for stuff like WARNINGs/OOPSes/...
where we have a backtrace, and some failed assertions, but we'll still
need to have a human come and fix it.

The goal here is to automate most of the filing BKCs so as we can start
distributing this filing responsibility to more sites (with a goal of
having one or two per site).

> 
>>
>>>
>>> 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.