Re: [Intel-gfx] BKM - Using JIRA Bugs for traceability

[Tahvanainen, Jari]

Sorry about this - Please delete.

BR, Jari

From: Tahvanainen, Jari
Sent: Wednesday, January 10, 2018 11:03 AM
To: otc gfx qa <otc.gfx...@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: BKM - Using JIRA Bugs for traceability
Importance: High

Hello folks,

Procedure FYI for the persons who are not executing tests in Jira.

GFX QA (and whoever does execution in Jira) shall follow the Rule: One must 
have traceability bugs (from Jira to fdo) for all the tests having FAIL or 
BLOCKED status. Note that on some cases one might not have the bug in fdo (e.g. 
security reasons), and on those cases all said below does not apply.

Note the following procedure when executing tests within Jira and having FAIL 
or BLOCKED verdict for the test

-  If there is failure on test case execution done in Jira (e.g. 
https://jira01.devtools.intel.com/secure/enav/#/57623) then one SHALL have bug 
as record for it. This was done correctly in this case by having defect 
attached to execution result - see

* Defects: 
VIZ-13164<https://jira01.devtools.intel.com/browse/VIZ-13164> --> 
fdo.104464<https://bugs.freedesktop.org/show_bug.cgi?id=104464>

-  In Jira side bug, in order traceability Feature-Test-Result to work 
correctly, one shall have Traceability in Labels (was not done for VIZ-13164, I 
fixed this). In addition to this title should include fdo.fdoID (as fdo.104464, 
was correctly done in this example),  priority should be set according the bug 
in fdo (was not done for VIZ-13164, I fixed this).

If the above rules are followed then we have enough information in title and as 
links for first glance, and also way to

-  Not to show this traceability bug on Jira queries - e.g. 
https://jira01.devtools.intel.com/issues/?jql=issuetype%20%3D%20Bug%20and%20%22Platform%2Fs%22%20in%20(%22Coffee%20Lake%22)%20and%20status%20not%20in%20(Closed%2C%20Resolved)%20AND%20(labels%20is%20empty%20OR%20labels%20not%20in%20(Traceability))%20order%20by%20priority%20desc%2C%20component%20asc

o   One should track all these bugs on fdo, and then GFX QA should follow up 
traceability bugs in Jira every now and then and e.g. close the ones in Jira 
which are marked as fixed in fdo.

?  BTW the query of CFL traceability bugs is 
https://jira01.devtools.intel.com/issues/?jql=issuetype%20%3D%20Bug%20and%20%22Platform%2Fs%22%20in%20(%22Coffee%20Lake%22)%20and%20status%20not%20in%20(Closed%2C%20Resolved)%20AND%20labels%20in%20(Traceability)%20order%20by%20priority%20desc%2C%20component%20asc

-  Have full traceability for test case failure in Jira to fdo for 
reporting and retesting when fdo bug is marked as fixed.

o   Reporting example (still PoC tool/script)

?  CFL PV  System Testing summary:  1  FAIL,  6  UNEXECUTED,  0  BLOCKED,  91 
PASS.  93 % RUN RATE,  92 % PASS RATE

* NOTE: some of the 73 tests were executed more than once in different 
environments giving total 98 executed

?  2DZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  26 PASS.  100 % RUN RATE,  
100 % PASS RATE

?  3DZephyr : 1  FAIL,  0  UNEXECUTED,  0  BLOCKED,  9 PASS.  100 % RUN RATE,  
90 % PASS RATE

* BUGS: VIZ-13164/[CFL][ TRACEABILITY] fdo.104464 -Poor frame rate on 
3D games

?  AppsZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  2 PASS.  100 % RUN RATE, 
 100 % PASS RATE

?  CTSZephyr : 0  FAIL,  3  UNEXECUTED,  0  BLOCKED,  0 PASS.  0 % RUN RATE,  0 
% PASS RATE

?  DEQZephyr : 0  FAIL,  2  UNEXECUTED,  0  BLOCKED,  0 PASS.  0 % RUN RATE,  0 
% PASS RATE

?  DmcZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  18 PASS.  100 % RUN RATE, 
 100 % PASS RATE

?  GucZephyr : 0  FAIL,  1  UNEXECUTED,  0  BLOCKED,  22 PASS.  95 % RUN RATE,  
95 % PASS RATE

?  HucZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  4 PASS.  100 % RUN RATE,  
100 % PASS RATE

?  Kernel - display : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  9 PASS.  100 % RUN 
RATE,  100 % PASS RATE

?  KernelZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  1 PASS.  100 % RUN 
RATE,  100 % PASS RATE

BR. Jari

1.PS. I also fixed (=added the Traceability on Labels for) 
VIZ-12145<https://jira01.devtools.intel.com/browse/VIZ-12145>, 
VIZ-12142<https://jira01.devtools.intel.com/browse/VIZ-12142> ...

   Jari Tahvanainen
   -
   Intel Finland Oy
   BIG 0357606-4
   Westendinkatu 7, 02160 Espoo

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

[Intel-gfx] BKM - Using JIRA Bugs for traceability

[Tahvanainen, Jari]

Hello folks,

Procedure FYI for the persons who are not executing tests in Jira.

GFX QA (and whoever does execution in Jira) shall follow the Rule: One must 
have traceability bugs (from Jira to fdo) for all the tests having FAIL or 
BLOCKED status. Note that on some cases one might not have the bug in fdo (e.g. 
security reasons), and on those cases all said below does not apply.

Note the following procedure when executing tests within Jira and having FAIL 
or BLOCKED verdict for the test

-  If there is failure on test case execution done in Jira (e.g. 
https://jira01.devtools.intel.com/secure/enav/#/57623) then one SHALL have bug 
as record for it. This was done correctly in this case by having defect 
attached to execution result - see

* Defects: 
VIZ-13164 --> 
fdo.104464

-  In Jira side bug, in order traceability Feature-Test-Result to work 
correctly, one shall have Traceability in Labels (was not done for VIZ-13164, I 
fixed this). In addition to this title should include fdo.fdoID (as fdo.104464, 
was correctly done in this example),  priority should be set according the bug 
in fdo (was not done for VIZ-13164, I fixed this).

If the above rules are followed then we have enough information in title and as 
links for first glance, and also way to

-  Not to show this traceability bug on Jira queries - e.g. 
https://jira01.devtools.intel.com/issues/?jql=issuetype%20%3D%20Bug%20and%20%22Platform%2Fs%22%20in%20(%22Coffee%20Lake%22)%20and%20status%20not%20in%20(Closed%2C%20Resolved)%20AND%20(labels%20is%20empty%20OR%20labels%20not%20in%20(Traceability))%20order%20by%20priority%20desc%2C%20component%20asc

o   One should track all these bugs on fdo, and then GFX QA should follow up 
traceability bugs in Jira every now and then and e.g. close the ones in Jira 
which are marked as fixed in fdo.

?  BTW the query of CFL traceability bugs is 
https://jira01.devtools.intel.com/issues/?jql=issuetype%20%3D%20Bug%20and%20%22Platform%2Fs%22%20in%20(%22Coffee%20Lake%22)%20and%20status%20not%20in%20(Closed%2C%20Resolved)%20AND%20labels%20in%20(Traceability)%20order%20by%20priority%20desc%2C%20component%20asc

-  Have full traceability for test case failure in Jira to fdo for 
reporting and retesting when fdo bug is marked as fixed.

o   Reporting example (still PoC tool/script)

?  CFL PV  System Testing summary:  1  FAIL,  6  UNEXECUTED,  0  BLOCKED,  91 
PASS.  93 % RUN RATE,  92 % PASS RATE

* NOTE: some of the 73 tests were executed more than once in different 
environments giving total 98 executed

?  2DZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  26 PASS.  100 % RUN RATE,  
100 % PASS RATE

?  3DZephyr : 1  FAIL,  0  UNEXECUTED,  0  BLOCKED,  9 PASS.  100 % RUN RATE,  
90 % PASS RATE

* BUGS: VIZ-13164/[CFL][ TRACEABILITY] fdo.104464 -Poor frame rate on 
3D games

?  AppsZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  2 PASS.  100 % RUN RATE, 
 100 % PASS RATE

?  CTSZephyr : 0  FAIL,  3  UNEXECUTED,  0  BLOCKED,  0 PASS.  0 % RUN RATE,  0 
% PASS RATE

?  DEQZephyr : 0  FAIL,  2  UNEXECUTED,  0  BLOCKED,  0 PASS.  0 % RUN RATE,  0 
% PASS RATE

?  DmcZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  18 PASS.  100 % RUN RATE, 
 100 % PASS RATE

?  GucZephyr : 0  FAIL,  1  UNEXECUTED,  0  BLOCKED,  22 PASS.  95 % RUN RATE,  
95 % PASS RATE

?  HucZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  4 PASS.  100 % RUN RATE,  
100 % PASS RATE

?  Kernel - display : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  9 PASS.  100 % RUN 
RATE,  100 % PASS RATE

?  KernelZephyr : 0  FAIL,  0  UNEXECUTED,  0  BLOCKED,  1 PASS.  100 % RUN 
RATE,  100 % PASS RATE

BR. Jari

1.PS. I also fixed (=added the Traceability on Labels for) 
VIZ-12145, 
VIZ-12142 ...

   Jari Tahvanainen
   -
   Intel Finland Oy
   BIG 0357606-4
   Westendinkatu 7, 02160 Espoo

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

Re: [Intel-gfx] [PATCH i-g-t v9] tests/kms_frontbuffer_tracking: Including DRRS test coverage

[Tahvanainen, Jari]

-Original Message-
> From: Lohith BS [mailto:lohith...@intel.com] 
> Sent: Monday, December 11, 2017 3:13 PM
> To: intel-gfx@lists.freedesktop.org; rodrigo.v...@intel.com; 
> jani.saari...@intel.com; daniel.vet...@ffwll.ch; ch...@chris-wilson.co.uk
> Cc: ankit.k.nauti...@intel.com; paulo.r.zan...@intel.com
> Subject: [v9] tests/kms_frontbuffer_tracking: Including DRRS test coverage
>
> Dynamic Refresh Rate Switch(DRRS) is used to switch the panel's refresh rate 
> to the lowest vrefresh supported by panel, when frame is not flipped > for 
> more than a Sec.
>
> In kernel, DRRS uses the front buffer tracking infrastructure.
> Hence DRRS test coverage is added along with other frontbuffer tracking based 
> features such as FBC and PSR tests.
>
> Here, we are testing DRRS with other features in all possible combinations, 
> in all required test cases, to capture any possible regression.
>
> v9: Addressed Paulo Zanoni comments.
> Check for DRRS_LOW at tests with OFFSCREEN + FBS_INDIVIDUAL.
>
> Signed-off-by: Lohith BS 
> Signed-off-by: aknautiy 
> ---
>  tests/kms_frontbuffer_tracking.c | 183 
> +--
>  1 file changed, 176 insertions(+), 7 deletions(-)

Tests are working as expected on a system without DRRS (result=skip for all 570 
new cases on SKL-i5-6600k).
kms_frontbuffer_tracking suite was executed once in both cases:
- baseline having IGT-Version: 1.20-gda0889bf (x86_64)  AND Linux: 
4.15.0-rc4-ezbench_e27ee23e076d+ x86_64
- baseline+patch
with 'no regression" on non-DRRS tests, skip for all DRRS tests on latter.
What should still be done is to have somebody check these tests with DRRS 
enabled display.

Tested-by: Jari Tahvanainen 
 
   Jari Tahvanainen
   -
   Intel Finland Oy
   BIG 0357606-4
   Westendinkatu 7, 02160 Espoo


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

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Try to recover from a wedged GPU during reset tests

[Tahvanainen, Jari]

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Tuesday, September 19, 2017 5:19 PM
To: intel-gfx@lists.freedesktop.org
Cc: Tahvanainen, Jari <jari.tahvanai...@intel.com>; Mika Kuoppala 
<mika.kuopp...@linux.intel.com>
Subject: Re: [PATCH] drm/i915/selftests: Try to recover from a wedged GPU 
during reset tests

Quoting Chris Wilson (2017-09-15 14:09:29)
> If we see the seqno stop progressing, we abandon the test for fear 
> that the GPU died following the reset. However, during test teardown 
> we still wait for the GPU to idle before continuing, but we have 
> already confirmed that the GPU is dead. Furthermore, since we are 
> inside a reset test, we have disabled the hangchecker, and so there is 
> no safety net and we wait indefinitely. Detect the stuck GPU and 
> declare it wedged as a state of emergency so we can escape.
> 
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Jari Tahvanainen <jari.tahvanai...@intel.com>
> Cc: Mika Kuoppala <mika.kuopp...@linux.intel.com>

>Ping?

Sorry Chris for late answer. Tried to get touch with you earlier through IRC.
I merged the series on top of the drm-tip and executed it in HSW - no hang 
anymore - FAIL.

(drv_selftest:6304) igt-kmod-CRITICAL: Test assertion failure function 
igt_kselftest_execute, file igt_kmod.c:513:
(drv_selftest:6304) igt-kmod-CRITICAL: Failed assertion: err == 0
(drv_selftest:6304) igt-kmod-CRITICAL: kselftest "i915 
igt__19__live_hangcheck=1 live_selftests=-1" failed: Input/output error [5]
(drv_selftest:6304) igt-core-INFO: Stack trace:
(drv_selftest:6304) igt-core-INFO:   #0 [__igt_fail_assert+0x101]
(drv_selftest:6304) igt-core-INFO:   #1 [igt_kselftest_execute+0x296]
(drv_selftest:6304) igt-core-INFO:   #2 [igt_kselftests+0x295]
(drv_selftest:6304) igt-core-INFO:   #3 [main+0x5f]
(drv_selftest:6304) igt-core-INFO:   #4 [__libc_start_main+0xf1]
(drv_selftest:6304) igt-core-INFO:   #5 [_start+0x2a]
(drv_selftest:6304) igt-core-INFO:   #6 [+0x2a]
  END  
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [igt_kselftest_execute+0x296]
  #2 [igt_kselftests+0x295]
  #3 [main+0x5f]
  #4 [__libc_start_main+0xf1]
  #5 [_start+0x2a]
  #6 [+0x2a]
Subtest live_hangcheck: FAIL (1.911s)

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

Re: [Intel-gfx] [PATCH] drm/i915: Disable DMC powersaving during GT operations

[Tahvanainen, Jari]

Hello,

+Ricardo related to testing done by GFX QA.

Br, Jari

-Original Message-
From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] 
Sent: Monday, September 18, 2017 4:41 PM
To: Chris Wilson <ch...@chris-wilson.co.uk>; intel-gfx@lists.freedesktop.org
Cc: Ursulin, Tvrtko <tvrtko.ursu...@intel.com>; Deak, Imre 
<imre.d...@intel.com>; Tahvanainen, Jari <jari.tahvanai...@intel.com>; Kaajas, 
Samu <samu.kaa...@intel.com>
Subject: Re: [PATCH] drm/i915: Disable DMC powersaving during GT operations

+ Jari & Samu

On Tue, 2017-09-12 at 13:48 +0100, Chris Wilson wrote:
> Quoting Chris Wilson (2017-09-12 13:37:32)
> > diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> > b/drivers/gpu/drm/i915/i915_gem_request.c
> > index 813a3b546d6e..3c8ebdb5b0b4 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_request.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> > @@ -254,6 +254,9 @@ static void mark_busy(struct drm_i915_private *i915)
> > intel_runtime_pm_get_noresume(i915);
> > i915->gt.awake = true;
> >  
> 
> /*
>  * The DMC doesn't behave well when it is active (i.e the system is
>  * idle). It continually tries to toggle DC_STATE_EN causing a
>  * severe slow down of the rest of the system (severe enough to 
> trigger
>  * watchdogs and reboot the machine under CI testing).
>  *
>  * Known affected firmware:
>  * - skl_dmc_ver1_26.bin
>  * - bxt_dmc_ver1_07.bin
>  */

Has this patch been tested more widely, does it have negative performance 
effects?

Regards, Joonas

> > +   if (i915->csr.dmc_payload)
> > +   intel_display_power_get(i915, POWER_DOMAIN_MODESET);
> > +
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [v2] igt/pm_rpm: Use libc 'ftw' rather than opencoding our own filetree walk

[Tahvanainen, Jari]

On Wed, Aug 23, 2017 at 05:06:42PM +0100, Chris Wilson wrote:
> By using ftw, we avoid the issue of having to handle directory recursion
> ourselves and can focus on the test of checking the reading a
> sysfs/debugfs does not break runtime suspend. In the process, disregard
> errors when opening the individual files as they may fail for other
> reasons.
> 
> v2: Bracket the file open/close with the wait_for_suspended() tests.
> Whilst the fd is open, it may be keeping the device awake, e.g.
> i915_forcewake_user.
> 
> Signed-off-by: Chris Wilson 
> ---
>  lib/igt_debugfs.c | 50 +-
>  lib/igt_debugfs.h |  1 +
>  lib/igt_sysfs.c   | 41 +++--
>  lib/igt_sysfs.h   |  1 +
>  tests/pm_rpm.c| 91 
> ---
>  5 files changed, 108 insertions(+), 76 deletions(-)
> 

Tested-by: Jari Tahvanainen 
On SKL (i5-6600k) improvement is visible in both sysfs-read and debugfs-read 
tests.
On 1000 repetitions both resulted to change from FAIL to SUCCESS for 1000 times 
on
 drm-tip: 2017y-08m-30d-08h-12m-34s UTC integration manifest
with igt commit 1f0f2aa014 + this series.
For HSW see https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_90/shards.html
Test pm_rpm:
Subgroup debugfs-read:
fail   -> PASS   (shard-hsw) fdo#100717
Subgroup sysfs-read:
fail   -> PASS   (shard-hsw) fdo#102242
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from DMC presence

[Tahvanainen, Jari]

" Do we have a bug about this at bugs.freedesktop.org?" I did quick query on 
fdo.bugzilla and did not find any matching item (afaik) from there (with 
i915_feature = GPU *hang*|*DMC*) so I would claim that bug is not filed. 
Stephane can correct my wrong sayings here. 

BR, Jari

-Original Message-
From: Jani Nikula [mailto:jani.nik...@linux.intel.com] 
Sent: Friday, August 18, 2017 12:08 PM
To: Stéphane Marchesin <marc...@chromium.org>
Cc: Deak, Imre <imre.d...@intel.com>; Rodrigo Vivi <rodrigo.v...@gmail.com>; 
intel-gfx@lists.freedesktop.org; Matt Atwood 
<matthew.s.atw...@intel.corp-partner.google.com>; Saarinen, Jani 
<jani.saari...@intel.com>; Tahvanainen, Jari <jari.tahvanai...@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915: decouple runtime PM enablement from 
DMC presence

On Thu, 17 Aug 2017, Stéphane Marchesin <marc...@chromium.org> wrote:
> On Mon, Jun 19, 2017 at 11:45 AM, Jani Nikula 
> <jani.nik...@linux.intel.com> wrote:
>>
>> On Thu, 15 Jun 2017, Imre Deak <imre.d...@intel.com> wrote:
>> > On Thu, Jun 15, 2017 at 10:20:57AM -0700, Rodrigo Vivi wrote:
>> >> I believe it is worth allowing RPM to work without requiring DMC, no?!
>> >
>> > Not if there is no good reason for not using DMC. It was decided 
>> > early on that we won't support that configuration since if you care 
>> > about the power saving provided by partially disabling things you 
>> > probably also care about the bigger power saving provided by DMC. 
>> > So that is the current state of the driver, enabling runtime PM 
>> > without having DMC loaded is not supported. Proper support for that 
>> > would need to be added after a justification why not to use the firmware.
>>
>> Agreed. We already have too many configurations to support, and we 
>> already struggle with our testing coverage as-is. Adding new 
>> configurations to be tested is not to be taken lightly.
>>
>
> For context, we are seeing GPU hangs at suspend/resume with DMC 
> enabled (feel free to email me if you want to be added to the internal
> bug) which is the reason for this patch. If those GPU hangs can be 
> fixed instead, then that would be an even better solution, IMO. Is 
> there someone on your side who could help with these hangs?

We need to get the GPU hangs fixed, obviously. Is this reproducible with 
upstream code? Do we have a bug about this at bugs.freedesktop.org?
Jani, Jari?

BR,
Jani.


>
> Stéphane
>
>>
>> BR,
>> Jani.
>>
>> --
>> Jani Nikula, Intel Open Source Technology Center

--
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: [Intel-gfx] [PATCH] dim: Jari as QA lead

[Tahvanainen, Jari]

>On Fri, 11 Aug 2017, Daniel Vetter <daniel.vet...@ffwll.ch> wrote:
> > Cc: "Tahvanainen, Jari" <jari.tahvanai...@intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> > ---
> >  dim | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/dim b/dim
> > index 2b377cb3a3f3..4a4c1adb2c68 100755
> > --- a/dim
> > +++ b/dim
> > @@ -89,7 +89,7 @@ addr_intel_gfx_maintainer1="Daniel Vetter 
> > <daniel.vet...@ffwll.ch>"
> >  addr_intel_gfx_maintainer2="Jani Nikula <jani.nik...@linux.intel.com>"
> >  addr_intel_gfx="intel-gfx@lists.freedesktop.org"
> >  addr_dri_devel="dri-de...@lists.freedesktop.org"
> > -addr_intel_qa="\"Christophe Prigent\" <christophe.prig...@intel.com>"
> > +addr_intel_qa="\"Tahvanainen, Jari\" <jari.tahvanai...@intel.com>"

> Please just make it Jari Tahvanainen. The comma might cause issues.
> With that, Acked-by: Jani Nikula <jani.nik...@intel.com>

Acked-by: Jari Tahvanainen <jari.tahvanai...@intel.com>

> BR,
> Jani.

> >  
> >  # integration configuration
> >  integration_config=nightly.conf

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

Re: [Intel-gfx] [Bug Report] Weekly progress report WW24

[Tahvanainen, Jari]

I like this new report.

Thank you Elizabeth and whoever has been working with you in order to make this 
happen.

BR, Jari

From: De La Torre Mena, ElizabethX
Sent: Monday, June 19, 2017 5:48 PM
To: intel-gfx@lists.freedesktop.org; linux-...@eclists.intel.com; otc gfx qa 
; Parenteau, Paul A ; 
Gilliam, Amy ; Hockemeier, Steven J 
; Saarinen, Jani ; 
Nikkanen, Kimmo ; Kaajas, Samu 
Subject: [Bug Report] Weekly progress report WW24

Highlights:

-  22 bugs open during the week

-  20 bugs closed during the week

-  359 total bugs remain open

-  16 bugs labeled ReadyForDev during the week

-  88 total bugs labeled ReadyForDev remain open

Details:

-  Bugs open during the week (by priority)

highest

1

high

1

medium

20

Total

22



https://bugs.freedesktop.org/report.cgi?x_axis_field=_axis_field=priority_axis_field=_redirect=1_format=report-table_desc_type=allwordssubstr_desc==DRI=DRM%2FIntel_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_status=RESOLVED_status=VERIFIED_status=CLOSED_status=NEEDINFO_status=PLEASETEST_type=allwordssubstr=_file_loc_type=allwordssubstr_file_loc=_whiteboard_type=allwordssubstr_whiteboard=_type=allwords=_id=_id_type=anyexact=substring==substring==substringNow_top=AND=creation_ts=greaterthaneq=2017-06-11=noop=noop==table=wrap

-  Bugs closed during the week (by priority)

highest

4

high

4

medium

12

Total

20


https://bugs.freedesktop.org/report.cgi?x_axis_field=_axis_field=priority_axis_field=_redirect=1_format=report-table_desc_type=allwordssubstr_desc==DRI=DRM%2FIntel_status=CLOSED_type=allwordssubstr=_file_loc_type=allwordssubstr_file_loc=_whiteboard_type=allwordssubstr_whiteboard=_type=allwords=_id=_id_type=anyexact=substring==substring==substringNow_top=AND=delta_ts=greaterthaneq=2017-06-11=delta_ts=lessthan=2017-06-19=noop=noop==table=wrap

-  Total Bugs(by priority)
highest

15

high

43

medium

288

low

11

lowest

2

Total

359

Re: [Intel-gfx] [01/15] drm/i915: Copy user requested buffers into the error state

[Tahvanainen, Jari]

See below [Jari]...

-Original Message-
From: Ben Widawsky [mailto:b...@bwidawsk.net] 
Sent: Tuesday, March 21, 2017 5:38 PM
To: Tahvanainen, Jari <jari.tahvanai...@intel.com>
Cc: Chris Wilson <ch...@chris-wilson.co.uk>; intel-gfx@lists.freedesktop.org
Subject: Re: [01/15] drm/i915: Copy user requested buffers into the error state

On 17-03-21 11:30:36, Tahvanainen, Jari wrote:
>Note that this is for all the patches in series, replied only on [1/15].
>
>See also https://bugs.freedesktop.org/show_bug.cgi?id=94001#c45
>

Jari, did you test this patch specifically? It would involve introspection of 
the error state.

[Jari]  like said I tested the patch series including this patch
" Note that this is for all the patches in series, replied only on 
[1/15]" 
  Tested-by " for https://patchwork.freedesktop.org/series/21377;

If this is not the way to do it then I need to stop.
And since being tester (not programmer) you need to tell more 
what do you mean with " would involve introspection of the error state".
What should be outcome? What skill shall have for it, etc.? If I cannot 
do it then assumable tested-by is not the thing that I will do in future.
>
>From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
>Sent: Thursday, March 16, 2017 3:20 PM
>To: intel-gfx@lists.freedesktop.org
>Cc: Ben Widawsky <b...@bwidawsk.net>
>Subject: [01/15] drm/i915: Copy user requested buffers into the error 
>state
>
>Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace 
>may use to indicate that it wants the contents of this buffer preserved 
>in the error state (/sys/class/drm/cardN/error) following a GPU hang 
>involving this batch.
>
>Use this at your discretion, the contents of the error state. although 
>compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for 
>all eternity (until the error state is destroyed).
>
>Based on an earlier patch by Ben Widawsky 
><b...@bwidawsk.net<mailto:b...@bwidawsk.net>>
>Signed-off-by: Chris Wilson 
><ch...@chris-wilson.co.uk<mailto:ch...@chris-wilson.co.uk>>
>Cc: Ben Widawsky <b...@bwidawsk.net<mailto:b...@bwidawsk.net>>
>Cc: Matt Turner <matts...@gmail.com<mailto:matts...@gmail.com>>
>Acked-by: Ben Widawsky <b...@bwidawsk.net<mailto:b...@bwidawsk.net>>
>Reviewed-by: Joonas Lahtinen 
><joonas.lahti...@linux.intel.com<mailto:joonas.lahti...@linux.intel.com
>>>
>
>
>Tested-by: Jari Tahvanainen <jari.tahvanai...@intel.com>
>
>
>
>for https://patchwork.freedesktop.org/series/21377 on my dev-SKL (i5-6600k) by 
>taking all the gem_exec_reloc cases to testlist (151 tests).
>
>Executing those as a full set through piglit was not successful due to 
>out-of-memory conditions at the end of the testlist with some (varying) gtt-xx 
>subcases causing "Command terminated by signal 9". cpu-xx did not signal any 
>problems.
>
>
>
>drm-tip: 2017y-03m-17d-08h-03m-19s without patch series produced:
>
>[151/151] skip: 2, pass: 120, fail: 29
>
>
>
>with patch series applied one gets:
>
>[121/151] pass: 121 |
>
>running: igt/gem_exec_reloc/gtt-28 - "Command terminated by signal 9"
>
>Taking rest as new testlist
>
>[30/30] skip: 2, pass: 30, dmesg-warn: 1
>
>having
>
>dmesg-warn: igt/gem_exec_reloc/readonly-32
>
>skip: igt/gem_exec_reloc/active-bsd1
>
>skip: igt/gem_exec_reloc/active-bsd2
>
>
>
>When running tests gtt-xx tests individually then result for all is pass.
>
>$ sudo ./gem_exec_reloc --run-subtest cpu-31
>
>IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ 
>x86_64)
>
>Subtest cpu-31: SUCCESS (3,760s)
>
>$ sudo ./gem_exec_reloc --run-subtest gtt-31
>
>IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ 
>x86_64)
>
>Subtest gtt-31: SUCCESS (25,313s)
>
>$ sudo ./gem_exec_reloc --run-subtest gtt-30
>
>IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ 
>x86_64)
>
>Subtest gtt-30: SUCCESS (11,196s)
>
>$ sudo ./gem_exec_reloc --run-subtest gtt-29
>
>IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ 
>x86_64)
>
>Subtest gtt-29: SUCCESS (5,198s)
>
>$ sudo ./gem_exec_reloc --run-subtest gtt-28
>
>IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ 
>x86_64)
>
>Subtest gtt-28: SUCCESS (2,543s)
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [01/15] drm/i915: Copy user requested buffers into the error state

[Tahvanainen, Jari]

Note that this is for all the patches in series, replied only on [1/15].

See also https://bugs.freedesktop.org/show_bug.cgi?id=94001#c45


From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
Sent: Thursday, March 16, 2017 3:20 PM
To: intel-gfx@lists.freedesktop.org
Cc: Ben Widawsky 
Subject: [01/15] drm/i915: Copy user requested buffers into the error state

Introduce a new execobject.flag (EXEC_OBJECT_CAPTURE) that userspace may
use to indicate that it wants the contents of this buffer preserved in
the error state (/sys/class/drm/cardN/error) following a GPU hang
involving this batch.

Use this at your discretion, the contents of the error state. although
compressed, are allocated with GFP_ATOMIC (i.e. limited) and kept for all
eternity (until the error state is destroyed).

Based on an earlier patch by Ben Widawsky 
>
Signed-off-by: Chris Wilson 
>
Cc: Ben Widawsky >
Cc: Matt Turner >
Acked-by: Ben Widawsky >
Reviewed-by: Joonas Lahtinen 
>


Tested-by: Jari Tahvanainen 



for https://patchwork.freedesktop.org/series/21377 on my dev-SKL (i5-6600k) by 
taking all the gem_exec_reloc cases to testlist (151 tests).

Executing those as a full set through piglit was not successful due to 
out-of-memory conditions at the end of the testlist with some (varying) gtt-xx 
subcases causing "Command terminated by signal 9". cpu-xx did not signal any 
problems.



drm-tip: 2017y-03m-17d-08h-03m-19s without patch series produced:

[151/151] skip: 2, pass: 120, fail: 29



with patch series applied one gets:

[121/151] pass: 121 |

running: igt/gem_exec_reloc/gtt-28 - "Command terminated by signal 9"

Taking rest as new testlist

[30/30] skip: 2, pass: 30, dmesg-warn: 1

having

dmesg-warn: igt/gem_exec_reloc/readonly-32

skip: igt/gem_exec_reloc/active-bsd1

skip: igt/gem_exec_reloc/active-bsd2



When running tests gtt-xx tests individually then result for all is pass.

$ sudo ./gem_exec_reloc --run-subtest cpu-31

IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ x86_64)

Subtest cpu-31: SUCCESS (3,760s)

$ sudo ./gem_exec_reloc --run-subtest gtt-31

IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ x86_64)

Subtest gtt-31: SUCCESS (25,313s)

$ sudo ./gem_exec_reloc --run-subtest gtt-30

IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ x86_64)

Subtest gtt-30: SUCCESS (11,196s)

$ sudo ./gem_exec_reloc --run-subtest gtt-29

IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ x86_64)

Subtest gtt-29: SUCCESS (5,198s)

$ sudo ./gem_exec_reloc --run-subtest gtt-28

IGT-Version: 1.17-g3e3c1cd (x86_64) (Linux: 4.11.0-rc2-ezbench_cb106cd+ x86_64)

Subtest gtt-28: SUCCESS (2,543s)

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

Re: [Intel-gfx] [2/2] drm/i915: Fix SKL cursor watermarks

[Tahvanainen, Jari]

I applied this patch (and [1/2] drm/i915: Extract intel_wm_plane_visible()) on 
top of drm-tip: 2017y-03m-14d-16h-04m-56s UTC integration manifest and run all 
igt/kms_chv_cursor_fail cases producing [36/36] pass: 36. Patch fixes the 
problem https://bugs.freedesktop.org/show_bug.cgi?id=100195.
Tested-by: Jari Tahvanainen 

BR, Jari

-Original Message-
From: ville.syrj...@linux.intel.com [mailto:ville.syrj...@linux.intel.com] 
Sent: Tuesday, March 14, 2017 5:11 PM
To: intel-gfx@lists.freedesktop.org
Subject: [2/2] drm/i915: Fix SKL cursor watermarks

From: Ville Syrjälä 

Use intel_wm_plane_visible() to determine cursor visibility for SKL+ also. 
Previously SKL+ would check the actual visibility which now conflicts with the 
assumptions in intel_legacy_cursor_update().

We also change SKL+ to compute the cursor watermarks based on the unclipped 
cursor size, just as we do on all the other platforms.
Using the clipped size could now result in garbage results.

Testcase: igt/kms_chv_cursor_fail
Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100195
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_pm.c | 44 +
 1 file changed, 31 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c 
index 3b0d379b6f38..e51370cd5787 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3361,19 +3361,29 @@ void skl_ddb_get_hw_state(struct drm_i915_private 
*dev_priv,
  * Caller should take care of dividing & rounding off the value.
  */
 static uint32_t
-skl_plane_downscale_amount(const struct intel_plane_state *pstate)
+skl_plane_downscale_amount(const struct intel_crtc_state *cstate,
+  const struct intel_plane_state *pstate)
 {
+   struct intel_plane *plane = to_intel_plane(pstate->base.plane);
uint32_t downscale_h, downscale_w;
uint32_t src_w, src_h, dst_w, dst_h;
 
-   if (WARN_ON(!pstate->base.visible))
+   if (WARN_ON(!intel_wm_plane_visible(cstate, pstate)))
return DRM_PLANE_HELPER_NO_SCALING;
 
/* n.b., src is 16.16 fixed point, dst is whole integer */
-   src_w = drm_rect_width(>base.src);
-   src_h = drm_rect_height(>base.src);
-   dst_w = drm_rect_width(>base.dst);
-   dst_h = drm_rect_height(>base.dst);
+   if (plane->id == PLANE_CURSOR) {
+   src_w = pstate->base.src_w;
+   src_h = pstate->base.src_h;
+   dst_w = pstate->base.crtc_w;
+   dst_h = pstate->base.crtc_h;
+   } else {
+   src_w = drm_rect_width(>base.src);
+   src_h = drm_rect_height(>base.src);
+   dst_w = drm_rect_width(>base.dst);
+   dst_h = drm_rect_height(>base.dst);
+   }
+
if (drm_rotation_90_or_270(pstate->base.rotation))
swap(dst_w, dst_h);
 
@@ -3389,6 +3399,7 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
 const struct drm_plane_state *pstate,
 int y)
 {
+   struct intel_plane *plane = to_intel_plane(pstate->plane);
struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
uint32_t down_scale_amount, data_rate;
uint32_t width = 0, height = 0;
@@ -3401,7 +3412,7 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
fb = pstate->fb;
format = fb->format->format;
 
-   if (pstate->plane->type == DRM_PLANE_TYPE_CURSOR)
+   if (plane->id == PLANE_CURSOR)
return 0;
if (y && format != DRM_FORMAT_NV12)
return 0;
@@ -3425,7 +3436,7 @@ skl_plane_relative_data_rate(const struct 
intel_crtc_state *cstate,
data_rate = width * height * fb->format->cpp[0];
}
 
-   down_scale_amount = skl_plane_downscale_amount(intel_pstate);
+   down_scale_amount = skl_plane_downscale_amount(cstate, intel_pstate);
 
return (uint64_t)data_rate * down_scale_amount >> 16;  } @@ -3717,7 
+3728,7 @@ static uint32_t skl_adjusted_plane_pixel_rate(const struct 
intel_crtc_state *cst
uint64_t pixel_rate;
 
/* Shouldn't reach here on disabled planes... */
-   if (WARN_ON(!pstate->base.visible))
+   if (WARN_ON(!intel_wm_plane_visible(cstate, pstate)))
return 0;
 
/*
@@ -3725,7 +3736,7 @@ static uint32_t skl_adjusted_plane_pixel_rate(const 
struct intel_crtc_state *cst
 * with additional adjustments for plane-specific scaling.
 */
adjusted_pixel_rate = cstate->pixel_rate;
-   downscale_amount = skl_plane_downscale_amount(pstate);
+   downscale_amount = skl_plane_downscale_amount(cstate, pstate);
 
pixel_rate = 

Re: [Intel-gfx] [PATCH i-g-t v2] Add atomic modesetting testlist

[Tahvanainen, Jari]

Hello folks,

I took some time and executed these tests on the latest drm-tip and would 
propose for fluent execution that we will have few test-groups excluded from 
this list with comment #FIXME and action to have bugs on each of these 
sub-groups aiming to take these out from excluded...

Exclude_tests: ["kms-busy@extended", "pipe-a-torture-move", 
blt-wf_vblank-vs-dpms",  "rcs-wf_vblank-vs-dpms",  "blt-wf_vblank-vs-modeset", 
"rcs-wf_vblank-vs-modeset", "blt-flip-vs-modeset", "render-flip-vs-modeset"], 
#FIXME - Excluded tests should be having bug in fdo for pushing tests to tests 
included one by one.

This give total 1146 igt tests to be executed.
I got the following outcome with SKL and drm-tip from yesterday. 
[1146/1146] skip: 639, pass: 486, dmesg-warn: 5, fail: 16

BR, Jari

-Original Message-
From: Ben Hassine, RamiX 
Sent: Tuesday, February 14, 2017 4:07 PM
To: intel-gfx@lists.freedesktop.org
Cc: Tahvanainen, Jari <jari.tahvanai...@intel.com>; Saarinen, Jani 
<jani.saari...@intel.com>; Lankhorst, Maarten <maarten.lankho...@intel.com>; 
Ben Hassine, RamiX <ramix.ben.hass...@intel.com>
Subject: [PATCH i-g-t v2] Add atomic modesetting testlist

This is atomic modesetting acceptance tests added to feat_profile.json.

v2: Add all kms test
---
 tests/feat_profile.json | 5 +
 1 file changed, 5 insertions(+)

diff --git a/tests/feat_profile.json b/tests/feat_profile.json index 
251dfd9..a2685db 100644
--- a/tests/feat_profile.json
+++ b/tests/feat_profile.json
@@ -3,5 +3,10 @@
 "include_tests" : "psr",
 "exclude_tests" : "",
 "target_rate" : 90
+},
+"atomic-modesetting": {
+   "include_tests": ["kms", "testdisplay"],
+   "exclude_tests": "",
+   "target_rate": 90
 }
 }
--
2.7.4

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

Re: [Intel-gfx] drm/edid: Don't print an error if the checksum of a CEA block is wrong

[Tahvanainen, Jari]

I applied this change on the couple-days old drm-tip, and was not able to get 
any "EDID checksum is invalid" messages with it on my SKL. Without this patch I 
could generate the ERROR quite easily by switching the outputs and displays 
manually.
I don't know if this hides something that it should not but it seem to work for 
the problem related the noise on Patchwork CI execution caused by these EDID 
checksum is invalid messages.

Tested-by: Jari Tahvanainen 

-Original Message-
From: Tomeu Vizoso [mailto:tomeu.viz...@collabora.com] 
Sent: Thursday, December 8, 2016 3:12 PM
To: linux-ker...@vger.kernel.org
Cc: Tomeu Vizoso ; Tomi Sarvela 
; intel-gfx@lists.freedesktop.org; David Airlie 
; dri-de...@lists.freedesktop.org; Daniel Vetter 

Subject: drm/edid: Don't print an error if the checksum of a CEA block is wrong

It's common to share screens within CI labs, and it's also common for KVM 
switches to alter the contents of the CEA block but leave the checksum outdated.

So in this case, print a debug message instead of an error.

References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
Cc: Chris Wilson 
Cc: Tomi Sarvela 
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Tomeu Vizoso 
---
 drivers/gpu/drm/drm_edid.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index 
6798c3ad9d53..db79bc949216 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1128,16 +1128,19 @@ bool drm_edid_block_valid(u8 *raw_edid, int block, bool 
print_bad_edid,
 
csum = drm_edid_block_checksum(raw_edid);
if (csum) {
-   if (print_bad_edid) {
-   DRM_ERROR("EDID checksum is invalid, remainder is 
%d\n", csum);
-   }
-
if (edid_corrupt)
*edid_corrupt = true;
 
/* allow CEA to slide through, switches mangle this */
-   if (raw_edid[0] != 0x02)
+   if (raw_edid[0] == CEA_EXT) {
+   DRM_DEBUG("EDID checksum is invalid, remainder is 
%d\n", csum);
+   DRM_DEBUG("Assuming a KVM switch modified the CEA block 
but left the original checksum\n");
+   } else {
+   if (print_bad_edid)
+   DRM_ERROR("EDID checksum is invalid, remainder 
is %d\n", csum);
+
goto bad;
+   }
}
 
/* per-block-type checks */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/vgem_basic: Retry the initial module unload in unload test

[Tahvanainen, Jari]

Late Tested-By: Jari Tahvanainen  

I executed in HSW 100 times a test list having only one prime_vgem test case 
and vgem_basic@unload.
With fix below: 100% pass for vgem_basic@unload
Without fix below: 100% skip for vgem_basic@unload

During last night I started 100 repetitions for fast-feedback.testlist on HSW:
100% pass for vgem_basic@unload with kernel build having the fix.

Verdict: fix works as expected and seem to remove the flip-flop behavior on 
vgem_basic@unload.

BR, Jari

On 10/18/2016 02:36 PM, Chris Wilson wrote:
> On Tue, Oct 18, 2016 at 02:25:21PM +0300, Petri Latvala wrote:
>> If executed too soon after prime_vgem tests, the vgem unload test 
>> fails due to its execbuffers still being handled in the kernel. Retry 
>> the unload three times with sleeps before reporting a skip.
> What happened to igt ensuring that the driver was idle before closing 
> a test? I guess that is complicated by the use of multiple drivers in 
> vgem.
>
> diff --git a/lib/drmtest.c b/lib/drmtest.c index 40bbff6..5d3aaa8 
> 100644
> --- a/lib/drmtest.c
> +++ b/lib/drmtest.c
> @@ -344,14 +344,18 @@ int drm_open_driver(int chipset)
>  fd = __drm_open_driver(chipset);
>  igt_skip_on_f(fd<0, "No known gpu found\n");
>   
> -   if (__sync_fetch_and_add(_count, 1))
> -   return fd;
> -
> +   /* For i915, at least, we ensure that the driver is idle before
> +* starting a test and we install an exit handler to wait until
> +* idle before quitting.
> +*/
>  if (is_i915_device(fd)) {
> -   gem_quiescent_gpu(fd);
> -   igt_install_exit_handler(quiescent_gpu_at_exit);
> +   if (__sync_fetch_and_add(_count, 1) == 0) {
> +   gem_quiescent_gpu(fd);
> +
> +   at_exit_drm_fd = __drm_open_driver(chipset);
> +   igt_install_exit_handler(quiescent_gpu_at_exit);
> +   }
>  }
> -   at_exit_drm_fd = __drm_open_driver(chipset);
>   
>  return fd;
>   }
>

Well I'll be damned, that's an obvious bugfix, regardless of its effects on 
vgem unload. Please push that with a descriptive commit message and
Reviewed-by: Petri Latvala .

How should vgem work be flushed properly? With this i915 flushing is guaranteed 
even if vgem is opened first, then i915, but such flushing won't be done if 
only vgem is opened (I see only vgem_slow doing that)...

Jari will soon reply about vgem unload with this change applied.




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

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

Re: [Intel-gfx] [PATCH] tests/igt: dmesg noise is a kernel failure

[Tahvanainen, Jari]

Double checking the full picture of the impact: 
- Current - test result value list for igt (=default piglit): pass, warn, 
dmesg-warn, fail, dmesg-fail, timeout, crash, incomplete
- Intent with proposal below - test result value list for igt (kernel testing): 
pass, warn, fail, dmesg-fail, timeout, crash, incomplete
Right or wrong?
Or will fail vanish from this list too like Chris said? Or will there be 
scenario where one can have fail without dmesg?

BR, Jari

-Original Message-
From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] 
Sent: Friday, October 7, 2016 10:12 AM
To: Daniel Vetter <daniel.vet...@ffwll.ch>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>; piglit 
discussion list <pig...@lists.freedesktop.org>; Ville Syrjälä 
<ville.syrj...@linux.intel.com>; Tahvanainen, Jari 
<jari.tahvanai...@intel.com>; Latvala, Petri <petri.latv...@intel.com>; Vetter, 
Daniel <daniel.vet...@intel.com>
Subject: Re: [PATCH] tests/igt: dmesg noise is a kernel failure

On Fri, Oct 07, 2016 at 09:06:31AM +0200, Daniel Vetter wrote:
> At least when testing the kernel. In normal programs pretty much all 
> the dmesg noise would simply be replaced by debug asserts, but in the 
> kernel we try rely hard to not fall over minor inconsistencies.
> 
> Still for CI purposes there's not really a difference, hence don't 
> treat it as such.
> 
> Motivated since once again I've seen a statistics where this was split 
> up, and then a reduction of "failures" (but in reality just trading 
> them in for more "warnings") praised as success.
> 
> v2: Clamp to "dmesg-fail" to keep dmesg noise easily identifiable 
> (Ville).
> 
> Cc: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
> Acked-by: Dylan Baker <dy...@pnwbakers.com>
> Cc: jari.tahvanai...@intel.com
> Cc: Petri Latvala <petri.latv...@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> ---
>  tests/igt.py | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/tests/igt.py b/tests/igt.py index 
> 7ebb03646b50..21e55e115654 100644
> --- a/tests/igt.py
> +++ b/tests/igt.py
> @@ -123,6 +123,10 @@ class IGTTest(Test):
>  else:
>  self.result.result = 'fail'
>  
> +# all dmesg noise is considered a test failure when testing the 
> kernel
> +if self.result.dmesg
> +self.result.result = 'dmesg-fail'

This is changing a fail to dmesg-fail. I hate that.
-Chris

--
Chris Wilson, Intel Open Source Technology Centre
-
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.

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