[PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Maarten Lankhorst]

---
 drivers/gpu/drm/i915/intel_display.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 39d1f30cd0c4..436374b08b69 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12176,6 +12176,7 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state)
 
 		if (old_crtc_state->active) {
 			intel_crtc_disable_planes(crtc, old_crtc_state->plane_mask);
+			WARN_ON(crtc->crc.opened);
 			dev_priv->display.crtc_disable(to_intel_crtc_state(old_crtc_state), state);
 			intel_crtc->active = false;
 			intel_fbc_disable(intel_crtc);
-- 
2.15.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Ville Syrjälä]

On Wed, Nov 08, 2017 at 12:11:30PM +0100, Maarten Lankhorst wrote:
> ---
>  drivers/gpu/drm/i915/intel_display.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 39d1f30cd0c4..436374b08b69 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12176,6 +12176,7 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state)
>  
>  		if (old_crtc_state->active) {
>  			intel_crtc_disable_planes(crtc, old_crtc_state->plane_mask);
> +			WARN_ON(crtc->crc.opened);

Why? I actually want to keep crc capture alive across a modeset to be
able to observe every crc coming out of the hardware. Without that there
is no good way to figure out which crcs are good and which are bad.

>  			dev_priv->display.crtc_disable(to_intel_crtc_state(old_crtc_state), state);
>  			intel_crtc->active = false;
>  			intel_fbc_disable(intel_crtc);
> -- 
> 2.15.0
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Jani Nikula]

Please use trybot (i.e. send patches to
intel-gfx-trybot@lists.freedesktop.org) for hacks that aren't intended
for upstream. Then they can be prioritized appropriately.

BR,
Jani.


On Wed, 08 Nov 2017, Maarten Lankhorst <maarten.lankhorst@linux.intel.com> wrote:
> ---
>  drivers/gpu/drm/i915/intel_display.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 39d1f30cd0c4..436374b08b69 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12176,6 +12176,7 @@ static void intel_atomic_commit_tail(struct drm_atomic_state *state)
>  
>  		if (old_crtc_state->active) {
>  			intel_crtc_disable_planes(crtc, old_crtc_state->plane_mask);
> +			WARN_ON(crtc->crc.opened);
>  			dev_priv->display.crtc_disable(to_intel_crtc_state(old_crtc_state), state);
>  			intel_crtc->active = false;
>  			intel_fbc_disable(intel_crtc);

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✗ Fi.CI.BAT: warning for HAX: WARN_ON(crtc->crc.opened during disable)

[Patchwork]

== Series Details ==

Series: HAX: WARN_ON(crtc->crc.opened during disable)
URL   : https://patchwork.freedesktop.org/series/33411/
State : warning

== Summary ==

Series 33411v1 HAX: WARN_ON(crtc->crc.opened during disable)
https://patchwork.freedesktop.org/api/1.0/series/33411/revisions/1/mbox/

Test chamelium:
        Subgroup dp-crc-fast:
                fail       -> PASS       (fi-kbl-7500u) fdo#102514
Test debugfs_test:
        Subgroup read_all_entries:
                pass       -> DMESG-WARN (fi-bdw-5557u)
                pass       -> DMESG-WARN (fi-bdw-gvtdvm)
Test kms_frontbuffer_tracking:
        Subgroup basic:
                pass       -> DMESG-WARN (fi-bdw-5557u) fdo#102473
                pass       -> DMESG-WARN (fi-bdw-gvtdvm)
Test kms_pipe_crc_basic:
        Subgroup hang-read-crc-pipe-a:
                pass       -> DMESG-WARN (fi-bdw-5557u)
                pass       -> DMESG-WARN (fi-bdw-gvtdvm)
        Subgroup nonblocking-crc-pipe-a:
                pass       -> DMESG-WARN (fi-bdw-5557u)
                pass       -> DMESG-WARN (fi-bdw-gvtdvm)
        Subgroup nonblocking-crc-pipe-a-frame-sequence:
                pass       -> DMESG-WARN (fi-bdw-5557u)
                pass       -> DMESG-WARN (fi-bdw-gvtdvm)
        Subgroup read-crc-pipe-a:
                pass       -> DMESG-WARN (fi-bdw-5557u)
                pass       -> DMESG-WARN (fi-bdw-gvtdvm)
        Subgroup read-crc-pipe-a-frame-sequence:
                pass       -> DMESG-WARN (fi-bdw-5557u)
                pass       -> DMESG-WARN (fi-bdw-gvtdvm)
        Subgroup suspend-read-crc-pipe-a:
                pass       -> DMESG-WARN (fi-bdw-5557u)
                pass       -> DMESG-WARN (fi-bdw-gvtdvm)

fdo#102514 https://bugs.freedesktop.org/show_bug.cgi?id=102514
fdo#102473 https://bugs.freedesktop.org/show_bug.cgi?id=102473

fi-bdw-5557u     total:289  pass:260  dwarn:8   dfail:0   fail:0   skip:21  time:445s
fi-bdw-gvtdvm    total:289  pass:257  dwarn:8   dfail:0   fail:0   skip:24  time:453s
fi-blb-e6850     total:289  pass:223  dwarn:1   dfail:0   fail:0   skip:65  time:377s
fi-bsw-n3050     total:289  pass:243  dwarn:0   dfail:0   fail:0   skip:46  time:538s
fi-bwr-2160      total:289  pass:183  dwarn:0   dfail:0   fail:0   skip:106 time:274s
fi-bxt-dsi       total:289  pass:259  dwarn:0   dfail:0   fail:0   skip:30  time:501s
fi-bxt-j4205     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:509s
fi-byt-j1900     total:289  pass:254  dwarn:0   dfail:0   fail:0   skip:35  time:493s
fi-byt-n2820     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:485s
fi-elk-e7500     total:289  pass:229  dwarn:0   dfail:0   fail:0   skip:60  time:429s
fi-gdg-551       total:289  pass:178  dwarn:1   dfail:0   fail:1   skip:109 time:263s
fi-glk-1         total:289  pass:261  dwarn:0   dfail:0   fail:0   skip:28  time:543s
fi-hsw-4770      total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:427s
fi-hsw-4770r     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:438s
fi-ivb-3520m     total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:484s
fi-ivb-3770      total:289  pass:260  dwarn:0   dfail:0   fail:0   skip:29  time:461s
fi-kbl-7500u     total:289  pass:264  dwarn:1   dfail:0   fail:0   skip:24  time:487s
fi-kbl-7567u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:483s
fi-kbl-r         total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:535s
fi-pnv-d510      total:289  pass:222  dwarn:1   dfail:0   fail:0   skip:66  time:570s
fi-skl-6260u     total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:465s
fi-skl-6600u     total:289  pass:262  dwarn:0   dfail:0   fail:0   skip:27  time:548s
fi-skl-6700hq    total:289  pass:263  dwarn:0   dfail:0   fail:0   skip:26  time:566s
fi-skl-6700k     total:289  pass:265  dwarn:0   dfail:0   fail:0   skip:24  time:518s
fi-skl-6770hq    total:289  pass:269  dwarn:0   dfail:0   fail:0   skip:20  time:503s
fi-skl-gvtdvm    total:289  pass:266  dwarn:0   dfail:0   fail:0   skip:23  time:456s
fi-snb-2520m     total:289  pass:250  dwarn:0   dfail:0   fail:0   skip:39  time:557s
fi-snb-2600      total:289  pass:249  dwarn:0   dfail:0   fail:0   skip:40  time:424s
Blacklisted hosts:
fi-cnl-y         total:289  pass:223  dwarn:0   dfail:0   fail:0   skip:24 
fi-glk-dsi       total:289  pass:258  dwarn:0   dfail:0   fail:1   skip:30  time:502s

748f2c6b4046b23a623b4af3799563ef3110bb0d drm-tip: 2017y-11m-08d-07h-50m-13s UTC integration manifest
44593b6d2b4f HAX: WARN_ON(crtc->crc.opened during disable)

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7010/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Chris Wilson]

Quoting Jani Nikula (2017-11-08 13:06:39)
> 
> Please use trybot (i.e. send patches to
> intel-gfx-trybot@lists.freedesktop.org) for hacks that aren't intended
> for upstream. Then they can be prioritized appropriately.

We don't have excess to the extended test run on trybot yet...
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Jani Nikula]

On Wed, 08 Nov 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> Quoting Jani Nikula (2017-11-08 13:06:39)
>> 
>> Please use trybot (i.e. send patches to
>> intel-gfx-trybot@lists.freedesktop.org) for hacks that aren't intended
>> for upstream. Then they can be prioritized appropriately.
>
> We don't have excess to the extended test run on trybot yet...

Marta, Martin, Tomi - this.

Though I believe Chris wants access not excess. ;)

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Tomi Sarvela]

On 08/11/17 17:27, Jani Nikula wrote:
> On Wed, 08 Nov 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>> Quoting Jani Nikula (2017-11-08 13:06:39)
>>>
>>> Please use trybot (i.e. send patches to
>>> intel-gfx-trybot@lists.freedesktop.org) for hacks that aren't intended
>>> for upstream. Then they can be prioritized appropriately.
>>
>> We don't have excess to the extended test run on trybot yet...
> 
> Marta, Martin, Tomi - this.
> 
> Though I believe Chris wants access not excess. ;)

Sssooo... shard-runs for Trybot? Only on success, or also on warning as 
with intel-gfx and igt?

The very recent change to run also f-feedback warnings on shards, and 
fixed vetting handling, will cause much more shardruns.

After KBL DMC update it could be taken to all the runs, instead of 
avoiding it because it's 20 minutes slower (and GLK is 30 minutes more 
slower)

We'll see if there's enough time in a day.

Tomi
-- 
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Jani Nikula]

On Wed, 08 Nov 2017, Tomi Sarvela <tomi.p.sarvela@intel.com> wrote:
> On 08/11/17 17:27, Jani Nikula wrote:
>> On Wed, 08 Nov 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>>> Quoting Jani Nikula (2017-11-08 13:06:39)
>>>>
>>>> Please use trybot (i.e. send patches to
>>>> intel-gfx-trybot@lists.freedesktop.org) for hacks that aren't intended
>>>> for upstream. Then they can be prioritized appropriately.
>>>
>>> We don't have excess to the extended test run on trybot yet...
>> 
>> Marta, Martin, Tomi - this.
>> 
>> Though I believe Chris wants access not excess. ;)
>
> Sssooo... shard-runs for Trybot? Only on success, or also on warning as 
> with intel-gfx and igt?
>
> The very recent change to run also f-feedback warnings on shards, and 
> fixed vetting handling, will cause much more shardruns.
>
> After KBL DMC update it could be taken to all the runs, instead of 
> avoiding it because it's 20 minutes slower (and GLK is 30 minutes more 
> slower)
>
> We'll see if there's enough time in a day.

IIUC there currently just isn't. The problem is, people are now running
their hack patches on the regular CI to get full runs, and we can't even
prioritize the stuff aimed at upstream over hacks.

BR,
Jani.


>
> Tomi

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Martin Peres]

On 08/11/17 17:59, Jani Nikula wrote:
> On Wed, 08 Nov 2017, Tomi Sarvela <tomi.p.sarvela@intel.com> wrote:
>> On 08/11/17 17:27, Jani Nikula wrote:
>>> On Wed, 08 Nov 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>>>> Quoting Jani Nikula (2017-11-08 13:06:39)
>>>>>
>>>>> Please use trybot (i.e. send patches to
>>>>> intel-gfx-trybot@lists.freedesktop.org) for hacks that aren't intended
>>>>> for upstream. Then they can be prioritized appropriately.
>>>>
>>>> We don't have excess to the extended test run on trybot yet...
>>>
>>> Marta, Martin, Tomi - this.
>>>
>>> Though I believe Chris wants access not excess. ;)
>>
>> Sssooo... shard-runs for Trybot? Only on success, or also on warning as 
>> with intel-gfx and igt?

Same as the rest.

>>
>> The very recent change to run also f-feedback warnings on shards, and 
>> fixed vetting handling, will cause much more shardruns.
>>
>> After KBL DMC update it could be taken to all the runs, instead of 
>> avoiding it because it's 20 minutes slower (and GLK is 30 minutes more 
>> slower)
>>
>> We'll see if there's enough time in a day.
> 
> IIUC there currently just isn't. The problem is, people are now running
> their hack patches on the regular CI to get full runs, and we can't even
> prioritize the stuff aimed at upstream over hacks.

Agreed. Developers are being nice to the system by pushing stuff to the
trybot rather than intel-gfx, so we should provide the same service,
albeit one with higher latency than intel-gfx@...

Let's however wait to know the impact of the changes Tomi made today
before increasing the workload even more (Run shards on WARNING BAT
results, and fixing the suppressed tests/machines handling) :s

As far as I can see, shards are not a problem right now though:
https://intel-gfx-ci.01.org/cibuglog/metrics.html

I propose waiting until next week before enabling shards on the trybot.

Martin
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Tomi Sarvela]

On 08/11/17 17:59, Jani Nikula wrote:
> On Wed, 08 Nov 2017, Tomi Sarvela <tomi.p.sarvela@intel.com> wrote:
>> On 08/11/17 17:27, Jani Nikula wrote:
>>> On Wed, 08 Nov 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>>>> Quoting Jani Nikula (2017-11-08 13:06:39)
>>>>>
>>>>> Please use trybot (i.e. send patches to
>>>>> intel-gfx-trybot@lists.freedesktop.org) for hacks that aren't intended
>>>>> for upstream. Then they can be prioritized appropriately.
>>>>
>>>> We don't have excess to the extended test run on trybot yet...
>>>
>>> Marta, Martin, Tomi - this.
>>>
>>> Though I believe Chris wants access not excess. ;)
>>
>> Sssooo... shard-runs for Trybot? Only on success, or also on warning as
>> with intel-gfx and igt?
>>
>> The very recent change to run also f-feedback warnings on shards, and
>> fixed vetting handling, will cause much more shardruns.
>>
>> After KBL DMC update it could be taken to all the runs, instead of
>> avoiding it because it's 20 minutes slower (and GLK is 30 minutes more
>> slower)
>>
>> We'll see if there's enough time in a day.
> 
> IIUC there currently just isn't. The problem is, people are now running
> their hack patches on the regular CI to get full runs, and we can't even
> prioritize the stuff aimed at upstream over hacks.

If there is possibility to prioritize lower by sending hacks to Trybot, 
it might be enough. I don't mind queue if more important stuff is tested 
timely and trybot comes later.

Tomi
-- 
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] HAX: WARN_ON(crtc->crc.opened during disable)

[Jani Nikula]

On Wed, 08 Nov 2017, Martin Peres <martin.peres@linux.intel.com> wrote:
> On 08/11/17 17:59, Jani Nikula wrote:
>> On Wed, 08 Nov 2017, Tomi Sarvela <tomi.p.sarvela@intel.com> wrote:
>>> On 08/11/17 17:27, Jani Nikula wrote:
>>>> On Wed, 08 Nov 2017, Chris Wilson <chris@chris-wilson.co.uk> wrote:
>>>>> Quoting Jani Nikula (2017-11-08 13:06:39)
>>>>>>
>>>>>> Please use trybot (i.e. send patches to
>>>>>> intel-gfx-trybot@lists.freedesktop.org) for hacks that aren't intended
>>>>>> for upstream. Then they can be prioritized appropriately.
>>>>>
>>>>> We don't have excess to the extended test run on trybot yet...
>>>>
>>>> Marta, Martin, Tomi - this.
>>>>
>>>> Though I believe Chris wants access not excess. ;)
>>>
>>> Sssooo... shard-runs for Trybot? Only on success, or also on warning as 
>>> with intel-gfx and igt?
>
> Same as the rest.
>
>>>
>>> The very recent change to run also f-feedback warnings on shards, and 
>>> fixed vetting handling, will cause much more shardruns.
>>>
>>> After KBL DMC update it could be taken to all the runs, instead of 
>>> avoiding it because it's 20 minutes slower (and GLK is 30 minutes more 
>>> slower)
>>>
>>> We'll see if there's enough time in a day.
>> 
>> IIUC there currently just isn't. The problem is, people are now running
>> their hack patches on the regular CI to get full runs, and we can't even
>> prioritize the stuff aimed at upstream over hacks.
>
> Agreed. Developers are being nice to the system by pushing stuff to the
> trybot rather than intel-gfx, so we should provide the same service,
> albeit one with higher latency than intel-gfx@...
>
> Let's however wait to know the impact of the changes Tomi made today
> before increasing the workload even more (Run shards on WARNING BAT
> results, and fixing the suppressed tests/machines handling) :s

Of course, we need to get BAT stabilized (again/more), but this is a
good change at least for now. I was getting a bit tired requesting
re-runs on something that obviously shouldn't break the things that were
reported broken.

> As far as I can see, shards are not a problem right now though:
> https://intel-gfx-ci.01.org/cibuglog/metrics.html
>
> I propose waiting until next week before enabling shards on the trybot.

Ack.

BR,
Jani.


>
> Martin
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx