Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

[He, Shuang]

Chated with Ben last week about this
It may be feasiable to have a fast.tests for intel-gpu-tools also

Thanks
 --Shuang

From: Yang, Guang A
Sent: Tuesday, April 15, 2014 11:46 PM
To: Vetter, Daniel; Barnes, Jesse; Widawsky, Benjamin; Wood, Thomas; Jin, 
Gordon; OTC GFX QA Extended; intel-gfx@lists.freedesktop.org
Subject: The whole round of i-g-t testing cost too long running time

Hi all,
I have discussed with Daniel about the running time for each cases before and 
we set the standard as 10M, if one can’t finish after running 10M we will see 
it as Timeout and report bug on FDO(such as :  Bug 
77474 - 
[PNV/IVB/HSW]igt/gem_tiled_swapping is slow and Bug 
77475 - 
[PNV/IVB/HSW]igt//kms_pipe_crc_basic/read-crc-pipe-A is slow)
Now the true status is that i-g-t have more than 650+ subcases, running a whole 
round of testing will cost such a long time on QA side(beside that Timeout 
cases), QA also need to spend more time to analysis the result changing on each 
platforms.
You can find an example with this page: 
http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=2778 for how long 
one testing round cost.
With the table of subtask:10831 on the page which for i-g-t test cases on BDW. 
Testing start at 19:16 PM and finished at 03:25 AM the next day, cost about 8 
hours to run 638 test cases.
Each cases finished less than 10M as we expect, but the full time it too large, 
especially the BDW is the powerful machine on our side, ILK or PNV may take 
more than 10 hours. We not only run i-g-t but also need to test the 
piglit/performance/media which already need time.
Do we have any solutions to reduce the running time for whole i-g-t? it’s a 
pressing problem for QA after seeing the i-g-t case count enhance from 50 
->600+.


Best Regards~~

Open Source Technology Center (OTC)
Terence Yang（杨光）
Tel: 86-021-61167360
iNet: 8821-7360

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

Re: [Intel-gfx] The whole round of i-g-t testing cost too long running time

[He, Shuang]

From: Vetter, Daniel
Sent: Wednesday, April 16, 2014 1:18 AM
To: Yang, Guang A; Barnes, Jesse; Widawsky, Benjamin; Wood, Thomas; Jin, 
Gordon; OTC GFX QA Extended; intel-gfx@lists.freedesktop.org; Parenteau, Paul 
A; Nikkanen, Kimmo
Subject: Re: The whole round of i-g-t testing cost too long running time

On 15/04/2014 17:46, Yang, Guang A wrote:
Hi all,
I have discussed with Daniel about the running time for each cases before and 
we set the standard as 10M, if one can't finish after running 10M we will see 
it as Timeout and report bug on FDO(such as :  Bug 
77474<https://bugs.freedesktop.org/show_bug.cgi?id=77474> - 
[PNV/IVB/HSW]igt/gem_tiled_swapping is slow and Bug 
77475<https://bugs.freedesktop.org/show_bug.cgi?id=77475> - 
[PNV/IVB/HSW]igt//kms_pipe_crc_basic/read-crc-pipe-A is slow)
Now the true status is that i-g-t have more than 650+ subcases, running a whole 
round of testing will cost such a long time on QA side(beside that Timeout 
cases), QA also need to spend more time to analysis the result changing on each 
platforms.
You can find an example with this page: 
http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=2778 for how long 
one testing round cost.
With the table of subtask:10831 on the page which for i-g-t test cases on BDW. 
Testing start at 19:16 PM and finished at 03:25 AM the next day, cost about 8 
hours to run 638 test cases.
Each cases finished less than 10M as we expect, but the full time it too large, 
especially the BDW is the powerful machine on our side, ILK or PNV may take 
more than 10 hours. We not only run i-g-t but also need to test the 
piglit/performance/media which already need time.
Do we have any solutions to reduce the running time for whole i-g-t? it's a 
pressing problem for QA after seeing the i-g-t case count enhance from 50 
->600+.
Ok there are a few cases where we can indeed make tests faster, but it will be 
work for us. And that won't really speed up much since we're adding piles more 
testcases at a pretty quick rate. And many of these new testcases are CRC 
based, so inheritely take some time to run.
[He, Shuang] OK, so it takes at least n/60 in usual case to have result 
detected plus additional execution time, depending on how many rounds of 
testing. We will be absolutely happy to see more tests coming that is useful

So I think longer-term we simply need to throw more machines at the problem and 
run testcases in parallel on identical machines.
[He, Shuang] This would be the perfect way to go if all tests are really 
feasible to take long time to run. If we get more identical test machines, then 
problem solved

Wrt analyzing issues I think the right approach for moving forward is:
a) switch to piglit to run tests, not just enumerate them. This will allow QA 
and developers to share testcase analysis.
[He, Shuang] Yes, though this could not actually accelerate the test. We could 
directly wrap over piglit to run testing (have other control process to monitor 
and collecting test results)

b) add automated analysis for time-consuming and error prone cases like dmesg 
warnings and backtraces. Thomas&I have just discussed a few ideas in this are 
in our 1:1 today.

Reducing the set of igt tests we run is imo pointless: The goal of igt is to 
hit corner-cases, arbitrarily selecting which kinds of corner-cases we test 
just means that we have a nice illusion about our test coverage.
[He, Shuang] I don't think select a subset of test cases to run is pointless. 
It's a trade-off between speed and correctness. For our nightly testing it's 
not so useful to run only a small set of testing. But for fast sanity testing, 
it should be easier, which is supposed to catch regression in major/critical 
functionality (So other developers and QA could continue their work).


Adding more people to the discussion.

Cheers, Daniel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 01/16] drm/i915: Expose latest 200 CRC value for pipe through debugfs

[He, Shuang]

Thank you Danmien for helping with this.
It's moving so fast. I'm looking forward we could create some automation test 
for media also

Thanks
--Shuang

> -Original Message-
> From: Lespiau, Damien
> Sent: Wednesday, October 16, 2013 1:55 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: He, Shuang
> Subject: [PATCH 01/16] drm/i915: Expose latest 200 CRC value for pipe through
> debugfs
> 
> From: Shuang He 
> 
> There are several points in the display pipeline where CRCs can be computed
> on the bits flowing there. For instance, it's usually possible to compute the
> CRCs of the primary plane, the sprite plane or the CRCs of the bits after the
> panel fitter (collectively called pipe CRCs).
> 
> v2: Quite a bit of rework here and there (Damien)
> 
> Signed-off-by: Shuang He 
> Signed-off-by: Damien Lespiau 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 33
> +
>  drivers/gpu/drm/i915/i915_drv.h | 16 
>  drivers/gpu/drm/i915/i915_irq.c | 35
> +++
>  drivers/gpu/drm/i915/i915_reg.h | 36
> +++-
>  4 files changed, 119 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 72d0458..e1d45aa 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -1732,6 +1732,36 @@ static int i915_pc8_status(struct seq_file *m, void
> *unused)
>   return 0;
>  }
> 
> +static int i915_pipe_crc(struct seq_file *m, void *data) {
> + struct drm_info_node *node = (struct drm_info_node *) m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + enum pipe pipe = (enum pipe)node->info_ent->data;
> + const struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[pipe];
> + int i;
> + int start;
> +
> + if (!IS_IVYBRIDGE(dev)) {
> + seq_puts(m, "unsupported\n");
> + return 0;
> + }
> +
> + start = atomic_read(&pipe_crc->slot) + 1;
> + seq_puts(m, " timestamp CRC1 CRC2 CRC3 CRC4
> CRC5\n");
> + for (i = 0; i < INTEL_PIPE_CRC_ENTRIES_NR; i++) {
> + const struct intel_pipe_crc_entry *entry =
> + &pipe_crc->entries[(start + i) %
> +INTEL_PIPE_CRC_ENTRIES_NR];
> +
> + seq_printf(m, "%12u %8x %8x %8x %8x %8x\n", entry->timestamp,
> +entry->crc[0], entry->crc[1], entry->crc[2],
> +entry->crc[3], entry->crc[4]);
> + }
> +
> + return 0;
> +}
> +
>  static int
>  i915_wedged_get(void *data, u64 *val)
>  {
> @@ -2247,6 +2277,9 @@ static struct drm_info_list i915_debugfs_list[] = {
>   {"i915_edp_psr_status", i915_edp_psr_status, 0},
>   {"i915_energy_uJ", i915_energy_uJ, 0},
>   {"i915_pc8_status", i915_pc8_status, 0},
> + {"i915_pipe_A_crc", i915_pipe_crc, 0, (void *)PIPE_A},
> + {"i915_pipe_B_crc", i915_pipe_crc, 0, (void *)PIPE_B},
> + {"i915_pipe_C_crc", i915_pipe_crc, 0, (void *)PIPE_C},
>  };
>  #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 6106d3d..6855d91 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1219,6 +1219,18 @@ struct i915_package_c8 {
>   } regsave;
>  };
> 
> +struct intel_pipe_crc_entry {
> + uint32_t timestamp;
> + uint32_t crc[5];
> +};
> +
> +#define INTEL_PIPE_CRC_ENTRIES_NR200
> +struct intel_pipe_crc {
> + struct intel_pipe_crc_entry entries[INTEL_PIPE_CRC_ENTRIES_NR];
> + enum intel_pipe_crc_source source;
> + atomic_t slot;
> +};
> +
>  typedef struct drm_i915_private {
>   struct drm_device *dev;
>   struct kmem_cache *slab;
> @@ -1423,6 +1435,10 @@ typedef struct drm_i915_private {
>   struct i915_dri1_state dri1;
>   /* Old ums support infrastructure, same warning applies. */
>   struct i915_ums_state ums;
> +
> +#ifdef CONFIG_DEBUG_FS
> + struct intel_pipe_crc pipe_crc[I915_MAX_PIPES]; #endif
>  } drm_i915_private_t;
> 
>  static inline struct drm_i915_private *to_i915(const struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 26753b6..d2074f1 100644
> --- a/drivers/gpu/drm/i915/

Re: [Intel-gfx] [PATCH] drm/i195/bxt: Add A1 stepping for Broxton

[He, Shuang]

> -Original Message-
> From: Jesse Barnes [mailto:jbar...@virtuousgeek.org]
> Sent: Saturday, March 21, 2015 3:17 AM
> To: He, Shuang; Gao, Ethan; intel-gfx@lists.freedesktop.org; Hoath, Nicholas
> Subject: Re: [Intel-gfx] [PATCH] drm/i195/bxt: Add A1 stepping for Broxton
> 
> On 03/20/2015 10:14 AM, shuang...@intel.com wrote:
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> > Task id: 6016
> > -Summary-
> > Platform  Delta  drm-intel-nightly  Series Applied
> > PNV -2  274/274  272/274
> > ILK  303/303  303/303
> > SNB  303/303  303/303
> > IVB -2  342/342  340/342
> > BYT  287/287  287/287
> > HSW  362/362  362/362
> > BDW  308/308  308/308
> > -Detailed-
> > Platform  Testdrm-intel-nightly  
> > Series Applied
> > *PNV  igt_gem_userptr_blits_minor-sync-interruptible  PASS(2)
> DMESG_WARN(1)PASS(1)
> > *PNV  igt_gen3_render_linear_blits  PASS(3)  CRASH(1)PASS(1)
> >  IVB  igt_gem_pwrite_pread_snooped-copy-performance
> DMESG_WARN(1)PASS(3)  DMESG_WARN(1)PASS(1)
> > *IVB  igt_gem_storedw_batches_loop_secure-dispatch  PASS(3)
> DMESG_WARN(1)PASS(1)
> > Note: You need to pay more attention to line start with '*'
> 
> I wonder what these warnings actually are... I've been seeing the
> userptr_blits tests on PNV trigger warnings in a lot of PRTS results
> lately, and it must be intermittent since this patch would have no
> effect on PNV.
> 
> Shuang, when do you think you'll be able to attach the dmesg snippets
> from failures like these to the  msgs?  Would make things easier to
> triage at least.
[He, Shuang] yeah, it makes sense, we will see how we can improve this

> 
> And do we have a bug open?  I don't see this particular issue listed in
> the igt failures at bugs.fdo, but it could be a dupe with some other
> warning there.
[He, Shuang] I'll forward this to QA guys working on kernel validation, see if 
they already have this tracked

Thanks
--Shuang
> 
> Thanks,
> Jesse

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

Re: [Intel-gfx] [PATCH i-g-t 1/2 v2] lib: Add media spin

[He, Shuang]

(He Shuang on behalf of Liu Lei)
Tested-by: Lei,Liu lei.a@intel.com

I-G-T test result:
./pm_sseu
IGT-Version: 1.9-g07be8fe (x86_64) (Linux: 
4.0.0-rc3_drm-intel-nightly_c09a3b_20150310+ x86_64)
Subtest full-enable: SUCCESS (0.010s)

Manually test result:
SSEU Device Info
Available Slice Total: 1
Available Subslice Total: 3
Available Subslice Per Slice: 3
Available EU Total: 23
Available EU Per Subslice: 8
Has Slice Power Gating: no
Has Subslice Power Gating: no
Has EU Power Gating: yes
SSEU Device Status
Enabled Slice Total: 1
Enabled Subslice Total: 3
Enabled Subslice Per Slice: 3
Enabled EU Total: 24
Enabled EU Per Subslice: 8

EU are enabled in pairs. Because one EU in a pair can be fused-off, it is 
possible to see such case where reported EU enabled is greater than reported EU 
available. The IGT test allows for this discrepancy and only fails if enabled 
is less than available, which can only happen if unwanted power gating is 
applied

Best wishes
Liu,Lei

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of jeff.mc...@intel.com
> Sent: Friday, March 13, 2015 1:52 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH i-g-t 1/2 v2] lib: Add media spin
> 
> From: Jeff McGee 
> 
> The media spin utility is derived from media fill. The purpose
> is to create a simple means to keep the render engine (media
> pipeline) busy for a controlled amount of time. It does so by
> emitting a batch with a single execution thread that spins in
> a tight loop the requested number of times. Each spin increments
> a counter whose final 32-bit value is written to the destination
> buffer on completion for checking. The implementation supports
> Gen8, Gen8lp, and Gen9.
> 
> v2: Apply the recommendations of igt.cocci.
> 
> Signed-off-by: Jeff McGee 
> ---
>  lib/Makefile.sources|   2 +
>  lib/intel_batchbuffer.c |  24 +++
>  lib/intel_batchbuffer.h |  22 ++
>  lib/media_spin.c| 540
> 
>  lib/media_spin.h|  39 
>  5 files changed, 627 insertions(+)
>  create mode 100644 lib/media_spin.c
>  create mode 100644 lib/media_spin.h
> 
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 76f353a..3d93629 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -29,6 +29,8 @@ libintel_tools_la_SOURCES = \
>   media_fill_gen8.c   \
>   media_fill_gen8lp.c \
>   media_fill_gen9.c   \
> + media_spin.h\
> + media_spin.c\
>   gen7_media.h\
>   gen8_media.h\
>   rendercopy_i915.c   \
> diff --git a/lib/intel_batchbuffer.c b/lib/intel_batchbuffer.c
> index 666c323..195ccc4 100644
> --- a/lib/intel_batchbuffer.c
> +++ b/lib/intel_batchbuffer.c
> @@ -40,6 +40,7 @@
>  #include "rendercopy.h"
>  #include "media_fill.h"
>  #include "ioctl_wrappers.h"
> +#include "media_spin.h"
> 
>  #include 
> 
> @@ -785,3 +786,26 @@ igt_fillfunc_t igt_get_gpgpu_fillfunc(int devid)
> 
>   return fill;
>  }
> +
> +/**
> + * igt_get_media_spinfunc:
> + * @devid: pci device id
> + *
> + * Returns:
> + *
> + * The platform-specific media spin function pointer for the device specified
> + * with @devid. Will return NULL when no media spin function is
> implemented.
> + */
> +igt_media_spinfunc_t igt_get_media_spinfunc(int devid)
> +{
> + igt_media_spinfunc_t spin = NULL;
> +
> + if (IS_GEN9(devid))
> + spin = gen9_media_spinfunc;
> + else if (IS_BROADWELL(devid))
> + spin = gen8_media_spinfunc;
> + else if (IS_CHERRYVIEW(devid))
> + spin = gen8lp_media_spinfunc;
> +
> + return spin;
> +}
> diff --git a/lib/intel_batchbuffer.h b/lib/intel_batchbuffer.h
> index fa8875b..62c8396 100644
> --- a/lib/intel_batchbuffer.h
> +++ b/lib/intel_batchbuffer.h
> @@ -300,4 +300,26 @@ typedef void (*igt_fillfunc_t)(struct
> intel_batchbuffer *batch,
>  igt_fillfunc_t igt_get_media_fillfunc(int devid);
>  igt_fillfunc_t igt_get_gpgpu_fillfunc(int devid);
> 
> +/**
> + * igt_media_spinfunc_t:
> + * @batch: batchbuffer object
> + * @dst: destination i-g-t buffer object
> + * @spins: number of loops to execute
> + *
> + * This is the type of the per-platform media spin functions. The
> + * platform-specific implementation can be obtained by calling
> + * igt_get_media_spinfunc().
> + *
> + * The media spin function emits a batchbuffer for the render engine with
> + * the media pipeline selected. The workload consists of a single thread
> + * which spins in a tight loop the requested number of times. E

Re: [Intel-gfx] [PATCH] drm/i915: Fixup legacy plane->crtc link for initial fb config

[He, Shuang]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, March 26, 2015 6:24 PM
> To: He, Shuang
> Cc: Gao, Ethan; intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fixup legacy plane->crtc link for
> initial fb config
> 
> On Thu, Mar 26, 2015 at 02:53:10AM -0700, shuang...@intel.com wrote:
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> > Task id: 6053
> > -Summary-
> > Platform  Delta  drm-intel-nightly  Series Applied
> > PNV -1  276/276  275/276
> > ILK  303/303  303/303
> > SNB  304/304  304/304
> > IVB  339/339  339/339
> > BYT  287/287  287/287
> > HSW  362/362  362/362
> > BDW  310/310  310/310
> > -Detailed-
> > Platform  Testdrm-intel-nightly  
> > Series Applied
> >  PNV  igt@gem_userptr_blits@minor-normal-sync
> DMESG_WARN(1)PASS(1)  DMESG_WARN(1)PASS(1)
> >
> WARNING:at_drivers/gpu/drm/i915/i915_gem_evict.c:#i915_gem_evict_vm
> [i915]()@WARNING:.* at .* i915_gem_evict_vm+0x
> >
> Modules_linked_in:dm_mod_b43_mac80211_iTCO_wdt_cfg80211_rfkill_iTC
> O_vendor_support_snd_hda_codec_conexant_snd_hda_codec_generic_pc
> spkr_serio_raw_i2c_i801_snd_hda_intel_snd_hda_controller_lpc_ich_mfd_
> core_snd_hda_codec_snd_hda_core_snd_hwdep_bcma_snd_pcm_snd_ti
> mer_snd_soundcore_wmi_joydev_battery_ac_acpi_cpufreq_i915_button_
> video_drm_kms_helper_drm_broadcom@Modules linked in: dm_mod .*
> iTCO_wdt .* rfkill iTCO_vendor_support snd_hda_codec_conexant
> snd_hda_codec_generic pcspkr serio_raw .* snd_hda_intel
> snd_hda_controller lpc_ich mfd_core snd_hda_codec snd_hda_core
> snd_hwdep bcma snd_pcm snd_timer snd soundcore wmi joydev battery ac
> acpi_cpufreq .* button video drm_kms_helper drm broadcom
> > #>]?i915_gem_evict_vm[i915]@i915_gem_evict_vm+0x
> > #>]i915_gem_evict_vm[i915]@i915_gem_evict_vm+0x
> >
> #>]i915_gem_execbuffer_reserve[i915]@i915_gem_execbuffer_reserve+0x
> > #>]i915_gem_do_execbuffer[i915]@i915_gem_do_execbuffer
> > #>]i915_gem_execbuffer2[i915]@i915_gem_execbuffer2+0x
> > #>]drm_ioctl[drm]@drm_ioctl+0x
> > #>]?i915_gem_execbuffer[i915]@i915_gem_execbuffer+0x
> > Note: You need to pay more attention to line start with '*'
> 
> I can't parse this really ... is this the old or the new dmesg? Also I
> guess we need to change the dmesg filtering in piglit a bit so that it
> still preserves the entire dmesg and only filters it to decide what the
> result should be.
[He, Shuang] First of all, this one have bug in our parsing script, there 
should be only one line for each kind of dmesg. Current implement in PRTS takes 
dmesg recorded by piglit and parsing it. Secondly, you're asking for automatic 
judgment (old or the new dmesg) that is very hard implement. For example, 
reference kernel result not having one dmesg doesn't mean it really doesn't 
have it, right? It really depend how much effort you spent on testing it and 
how often the dmesg could be triggered. From my point of view, in the near 
future, the best we can have, is giving you the dmesg that may interest you 
instead of do that very advanced judgment for you.

Thanks
--Shuang
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fixup legacy plane->crtc link for initial fb config

[He, Shuang]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Thursday, March 26, 2015 9:13 PM
> To: He, Shuang
> Cc: Daniel Vetter; Gao, Ethan; intel-gfx@lists.freedesktop.org;
> daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fixup legacy plane->crtc link for
> initial fb config
> 
> On Thu, Mar 26, 2015 at 11:08:00AM +, He, Shuang wrote:
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > > Vetter
> > > Sent: Thursday, March 26, 2015 6:24 PM
> > > To: He, Shuang
> > > Cc: Gao, Ethan; intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch
> > > Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fixup legacy plane->crtc link 
> > > for
> > > initial fb config
> > >
> > > On Thu, Mar 26, 2015 at 02:53:10AM -0700, shuang...@intel.com wrote:
> > > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> > > shuang...@intel.com)
> > > > Task id: 6053
> > > > -Summary-
> > > > Platform  Delta  drm-intel-nightly  Series 
> > > > Applied
> > > > PNV -1  276/276  275/276
> > > > ILK  303/303  303/303
> > > > SNB  304/304  304/304
> > > > IVB  339/339  339/339
> > > > BYT  287/287  287/287
> > > > HSW  362/362  362/362
> > > > BDW  310/310  310/310
> > > > -Detailed-
> > > > Platform  Testdrm-intel-nightly 
> > > >  Series Applied
> > > >  PNV  igt@gem_userptr_blits@minor-normal-sync
> > > DMESG_WARN(1)PASS(1)  DMESG_WARN(1)PASS(1)
> > > >
> > >
> WARNING:at_drivers/gpu/drm/i915/i915_gem_evict.c:#i915_gem_evict_vm
> > > [i915]()@WARNING:.* at .* i915_gem_evict_vm+0x
> > > >
> > >
> Modules_linked_in:dm_mod_b43_mac80211_iTCO_wdt_cfg80211_rfkill_iTC
> > >
> O_vendor_support_snd_hda_codec_conexant_snd_hda_codec_generic_pc
> > >
> spkr_serio_raw_i2c_i801_snd_hda_intel_snd_hda_controller_lpc_ich_mfd_
> > >
> core_snd_hda_codec_snd_hda_core_snd_hwdep_bcma_snd_pcm_snd_ti
> > >
> mer_snd_soundcore_wmi_joydev_battery_ac_acpi_cpufreq_i915_button_
> > > video_drm_kms_helper_drm_broadcom@Modules linked in:
> dm_mod .*
> > > iTCO_wdt .* rfkill iTCO_vendor_support snd_hda_codec_conexant
> > > snd_hda_codec_generic pcspkr serio_raw .* snd_hda_intel
> > > snd_hda_controller lpc_ich mfd_core snd_hda_codec snd_hda_core
> > > snd_hwdep bcma snd_pcm snd_timer snd soundcore wmi joydev
> battery ac
> > > acpi_cpufreq .* button video drm_kms_helper drm broadcom
> > > > #>]?i915_gem_evict_vm[i915]@i915_gem_evict_vm+0x
> > > > #>]i915_gem_evict_vm[i915]@i915_gem_evict_vm+0x
> > > >
> > >
> #>]i915_gem_execbuffer_reserve[i915]@i915_gem_execbuffer_reserve+0x
> > > > #>]i915_gem_do_execbuffer[i915]@i915_gem_do_execbuffer
> > > > #>]i915_gem_execbuffer2[i915]@i915_gem_execbuffer2+0x
> > > > #>]drm_ioctl[drm]@drm_ioctl+0x
> > > > #>]?i915_gem_execbuffer[i915]@i915_gem_execbuffer+0x
> > > > Note: You need to pay more attention to line start with '*'
> > >
> > > I can't parse this really ... is this the old or the new dmesg? Also I
> > > guess we need to change the dmesg filtering in piglit a bit so that it
> > > still preserves the entire dmesg and only filters it to decide what the
> > > result should be.
> > [He, Shuang] First of all, this one have bug in our parsing script,
> > there should be only one line for each kind of dmesg. Current implement
> > in PRTS takes dmesg recorded by piglit and parsing it. Secondly, you're
> > asking for automatic judgment (old or the new dmesg) that is very hard
> > implement. For example, reference kernel result not having one dmesg
> > doesn't mean it really doesn't have it, right? It really depend how much
> > effort you spent on testing it and how often the dmesg could be
> > triggered. From my point 

Re: [Intel-gfx] [PATCH] drm: Kernel Crash in drm_unlock

[He, Shuang]

> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Damien Lespiau
> Sent: Tuesday, March 31, 2015 9:44 PM
> To: Antoine, Peter
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm: Kernel Crash in drm_unlock
> 
> On Tue, Mar 31, 2015 at 02:38:15PM +0100, Antoine, Peter wrote:
> > Patch ordering, is deliberate. They are not dependent on each other.
> > I'll rebase and add the new  dri-de...@lists.freedesktop.org when is
> > resubmit the patches.
> 
> Ah, well, huummm. That is something new and innovative for sure. I
> haven't seen any precedent for this one. I'd rather we always do the
> same thing to makes tools easier to write on top of the upstream
> mailing-list centered process, otherwise it'll be painful. For instance
> is PRTS going to cope? patchwork now sees all the patches as 1/3:
> 
>   http://patchwork.lespiau.name/series/1290/
[He, Shuang] PRTS is treating each one as a single patch

Thanks
--Shuang
> 
> We could make the tool understand that, but I believe it'll be much
> easier if we stick to the somewhat established conventions.
> 
> HTH,
> 
> --
> Damien
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 20/20] drm/i915: Enable skylake sprite plane scaling using shared scalers

[He, Shuang]

Hi, Chandra
Yes, I agree
There is some noise pre-existing bugs, you can ignore it for now. We're 
figuring out an way to filter them out

Thanks
--Shuang

> -Original Message-
> From: Konduru, Chandra
> Sent: Friday, April 3, 2015 1:21 AM
> To: He, Shuang; Gao, Ethan; intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH 20/20] drm/i915: Enable skylake sprite plane
> scaling using shared scalers
> 
> Hi Shuang,
> Looking at starting with '*':
> *BYT  igt@gem_exec_bad_domains@conflicting-write-domain  PASS(9)
> FAIL(1)PASS(1)
> 
> Above failure seems unrelated to my patch series. I suspect this
> pre-exist before my changes.
> Can you double check whether above failure is pre-existing before
> any action is taken from my side?
> 
> Also I just ran it on skl (that's the system I have) without any failures:
> ~/gfx/sources/intel-gpu-tools/tests$ sudo ./gem_exec_bad_domains
> IGT-Version: 1.10-g4f076bc (x86_64) (Linux: 4.0.0-rc3+ x86_64)
> Subtest cpu-domain: SUCCESS (0.004s)
> Subtest gtt-domain: SUCCESS (0.000s)
> Subtest conflicting-write-domain: SUCCESS (0.000s)
> Subtest double-write-domain: SUCCESS (0.000s)
> Subtest invalid-gpu-domain: SUCCESS (0.000s)
> ~/gfx/sources/intel-gpu-tools/tests$
> 
> 
> -Chandra
> 
> > -Original Message-
> > From: He, Shuang
> > Sent: Thursday, April 02, 2015 7:45 AM
> > To: He, Shuang; Gao, Ethan; intel-gfx@lists.freedesktop.org; Konduru,
> Chandra
> > Subject: RE: [Intel-gfx] [PATCH 20/20] drm/i915: Enable skylake sprite plane
> > scaling using shared scalers
> >
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> > shuang...@intel.com) Task id: 6118
> > -Summary-
> > Platform  Delta  drm-intel-nightly  Series Applied
> > PNV -1  272/272  271/272
> > ILK  302/302  302/302
> > SNB  303/303  303/303
> > IVB  338/338  338/338
> > BYT -1  287/287  286/287
> > HSW  361/361  361/361
> > BDW  308/308  308/308
> > -Detailed-
> > Platform  Testdrm-intel-nightly  
> > Series Applied
> >  PNV  igt@gen3_render_tiledx_blits  FAIL(6)PASS(3)  FAIL(2)
> > *BYT  igt@gem_exec_bad_domains@conflicting-write-domain  PASS(9)
> > FAIL(1)PASS(1)
> > Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] tests: Fix duplicate 'kms_flip_event_leak' entry in tests/Makefile.sources

[He, Shuang]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Wednesday, April 8, 2015 4:15 PM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] tests: Fix duplicate 'kms_flip_event_leak'
> entry in tests/Makefile.sources
> 
> On Tue, Apr 19, 2011 at 04:16:06AM +0800, Shuang He wrote:
> > Or, it will cause piglit failure to run I-G-T test case
> >
> > Signed-off-by: Shuang He 
> 
> How does it fail? And please fix the time on your machine, date on the
> mail is 2011 ;-)
[He, Shuang]  Piglit is now checking duplicate case name. and duplicate 
'kms_flip_event_leak' in I-G-T will directly lead piglit abort testing from 
start. Following are output of it:
./piglit-run.py -d tests/igt.py t
Error: A test has already been asigned the name: igt@kms_flip_event_leak
and both tests are the same.

Thanks
--Shuang
> -Daniel
> 
> > ---
> >  tests/Makefile.sources | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 3e3aa57..aded08f 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -85,7 +85,6 @@ TESTS_progs_M = \
> > kms_flip \
> > kms_flip_event_leak \
> > kms_flip_tiling \
> > -   kms_flip_event_leak \
> > kms_mmio_vs_cs_flip \
> > kms_pipe_b_c_ivb \
> > kms_pipe_crc_basic \
> > --
> > 1.9.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] tests: Fix duplicate 'kms_flip_event_leak' entry in tests/Makefile.sources

[He, Shuang]

> -Original Message-
> From: He, Shuang
> Sent: Wednesday, April 8, 2015 4:16 PM
> To: Daniel Vetter
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] tests: Fix duplicate 'kms_flip_event_leak'
> entry in tests/Makefile.sources
> 
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Wednesday, April 8, 2015 4:15 PM
> > To: He, Shuang
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] tests: Fix duplicate 'kms_flip_event_leak'
> > entry in tests/Makefile.sources
> >
> > On Tue, Apr 19, 2011 at 04:16:06AM +0800, Shuang He wrote:
> > > Or, it will cause piglit failure to run I-G-T test case
> > >
> > > Signed-off-by: Shuang He 
> >
> > How does it fail? And please fix the time on your machine, date on the
> > mail is 2011 ;-)
> [He, Shuang]  Piglit is now checking duplicate case name. and duplicate
> 'kms_flip_event_leak' in I-G-T will directly lead piglit abort testing from 
> start.
> Following are output of it:
> ./piglit-run.py -d tests/igt.py t
> Error: A test has already been asigned the name: igt@kms_flip_event_leak
> and both tests are the same.
[He, Shuang] Could anyone follow up this one? It's blocking our testing, though 
we could kind of work around it.

Thanks
--Shuang

> 
> Thanks
>   --Shuang
> > -Daniel
> >
> > > ---
> > >  tests/Makefile.sources | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > > index 3e3aa57..aded08f 100644
> > > --- a/tests/Makefile.sources
> > > +++ b/tests/Makefile.sources
> > > @@ -85,7 +85,6 @@ TESTS_progs_M = \
> > >   kms_flip \
> > >   kms_flip_event_leak \
> > >   kms_flip_tiling \
> > > - kms_flip_event_leak \
> > >   kms_mmio_vs_cs_flip \
> > >   kms_pipe_b_c_ivb \
> > >   kms_pipe_crc_basic \
> > > --
> > > 1.9.1
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue items in

[He, Shuang]

> -Original Message-
> From: He, Shuang
> Sent: Monday, October 20, 2014 9:47 PM
> To: He, Shuang; intel-gfx@lists.freedesktop.org; Daniel, Thomas
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue items 
> in
> 
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
[He, Shuang] Hello, there's definitely something wrong with this test result, I 
will check what happened

Thanks
--Shuang
> -Summary-
> Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
> BYT: pass/total=1/1->1/1
> PNV: pass/total=1/1->1/1
> ILK: pass/total=1/1->1/1
> IVB: pass/total=1/1->1/1
> SNB: pass/total=1/1->1/1
> HSW: pass/total=1/1->1/1
> BDW: pass/total=1/1->1/1
> -Detailed-
> test_platform: test_suite, test_case,
> result_with_drm_intel_nightly->result_with_patch_applied
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [Announcement] PRTS is now enabled for Intel-gfx for Kernel patch testing

[He, Shuang]

Hi, All
 As you may already noticed that, patches for kernel sent to this 
intel-gfx mailing list is automatically picked up for testing.
Test Reports that covered 7 intel platforms are replied to the patches.

At the moment, this functionality only covers patches sent by Intel Engineers
If you get any confusion or concern or suggestion, please feel to contact us 
(Intel PRC QA): Shuang He mailto:shuang...@intel.com>>

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

Re: [Intel-gfx] [PATCH] drm/i915: Delete outdated comment in

[He, Shuang]

> -Original Message-
> From: Lespiau, Damien
> Sent: Thursday, November 13, 2014 8:28 PM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org; daniel.vet...@ffwll.ch
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Delete outdated comment in
> 
> Hi,
> 
> This is a great example that shows that either some tests or the testing
> methodology are not quite right and need a few more iterations.
[He, Shuang] Thanks for your great feedback. Actually I'm also curious why no 
one is asking how the result is formatted (I thought engineers are 
concentrating on codes only:)). It definitely need improvement.

> 
> This patch just removes a comment, so the ideal case is no delta in the
> test results. Two things that may help improving the situation.
> 
>   1/ Some tests may be unreliable. It's be great to have a way to mark
>   them as such and display that state in the results so we don't worry
>   too much if an unreliable test fails. I think the test itself is a
>   great place to store that information.
[He, Shuang] We have already tried our best to remove as many unreliable tests 
as possible. Actually my query will only select pass many times in the recent 
testing, and no fail result in recent testing. But still no luck, we still have 
kind of noise there. Yi and one of our GB has spent great effort recently to 
have known unstable tests blacklisted, while combine those works together there 
is still unreliable test case show randomly. And actually these unreliable 
tests greatly impact bisection efficiency. That's one of major reason that PRTS 
is now using that blacklist as nightly does (PRTS used to run all test cases).

> 
>   2/ The reference against which this delta is taken seems not
>   completely up to date, otherwise we would have fewer failing cases?
[He, Shuang] The only thing I can guarantee is baseline results are based on 
the same kernel commit, while it might run on a different hardware. In our 
design, our script will re-run diff results (patched result compared with 
baseline result) on same test machine (the machine your patch is tested).

> 
> Some other remarks:
> 
> - I don't actually understand some of the delta shown:
> 
>   IVB: Intel_gpu_tools, igt_gem_bad_reloc_negative-reloc, NSPT(7,
> M21M34M4)PASS(12, M34M21M4) -> NSPT(1, M34)PASS(3, M34)
> 
>   going from NPST to NSPT, which is that line shown? IVB shows
>   pass/total=545/546->545/546 and yet we have two IVB lines in the
>   details
[He, Shuang] 545/546->546/546 simply means the pass rate doesn't change, while 
in some cases that result changed while keep the passrate unchanged. For 
example, 1 case change from PASS to NSPT, while another case changed from NSPT 
to PASS, you will see the passrate doesn't change. But the truth is there is 
some change happened, and we have to let you know about it. And for NSPT->NSPT 
as you noticed, is actually have sometime passed and sometime NSPT with 
baseline kernel, and it also sometime get NSPT and sometime get PASS with 
patched kernel. Before we have one solid way to tell if one test case is really 
unreliable in an automatically, telling you the truth we have is the best we 
can do right now.

> 
> - What does 'count' means in the results below?
[He, Shuang] The count means how many times the test case get that result

> 
> - The results are somewhat hard to read and would benefit from a bit
>   more formatting, even if just alignment of columns.
[He, Shuang] Yes, it absolutely need more refinement. I would be very happen to 
apply them if you have any suggestion

> 
> - You're missing the In-reply-to header in your answers which breaks
>   mail threading
[He, Shuang] It is in the header. You could check archieve of intel-gfx mailing 
list http://lists.freedesktop.org/archives/intel-gfx/2014-November/thread.html. 
It's correctly threaded by intel-gfx mailing

> 
> - It'd be great to have public links with logs to inspect the failure
>   cases.
[He, Shuang] that is one exactly same concern I had also, since we can't send 
internal link to external mailing list. While we need one way to hold logs

Thanks
--Shuang

> 
> Thanks!
> 
> --
> Damien
> 
> On Wed, Nov 12, 2014 at 11:21:35PM -0800, shuang...@intel.com wrote:
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> > -Summary-
> > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
> > BYT: pass/total=291/291->290/291
> > PNV: pass/total=356/356->356/356
> > ILK: pass/total=372/372->365/372
> > IVB: pass/total=545/546->545/546
> > SNB: pass/total=380/380->379/380
> > HSW: pass/total=579/579-

Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0

[He, Shuang]

> -Original Message-
> From: Lespiau, Damien
> Sent: Saturday, November 15, 2014 6:55 PM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for 
> eDP/DPLL0
> 
> Hi Shuang,
> 
> You wanted suggestions, so how about:
> 
> For both examples, to determine the size of the column, I'd take the
> length of the longest value of that column (including the title) and add
> 4 to account for spacing. Left alignment for text, right alignement for
> numbers (of course, all of that is debatable).
[He, Shuang] Hello, Damien, Thanks for your great input, we'll check how those 
suggestion could be integrated, I've created one jira task to track it: 
https://jira01.devtools.intel.com/browse/VIZ-4672

> 
> On Fri, Nov 14, 2014 at 09:28:03PM -0800, shuang...@intel.com wrote:
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> > -Summary-
> > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
> > BYT: pass/total=290/291->290/291
> > PNV: pass/total=352/356->356/356
> > ILK: pass/total=371/372->364/372
> > IVB: pass/total=545/546->545/546
> > SNB: pass/total=424/425->424/425
> > HSW: pass/total=579/579->579/579
> > BDW: pass/total=434/435->434/435
> 
> For this one:
> 
>   - a bit more spacing
>   - some table-like alignment. That's assuming the mail client will use
> monospaced fonts for text emails, it really should.
>   - add the delta so it's easier to parse the interesting information
>   - sort by gens
[He, Shuang] yes, this makes sense

>   - baseline_drm_intel_nightly_pass_rate can really just be
> drm-intel-nightly
[He, Shuang] yes, this makes sense

>   - it's not just a single patch applied, so series applied?
[He, Shuang] yes, it's series applied

> 
> PlatformDeltadrm-intel-nightlySeries Applied
> 
> PNV+4  352/356   356/356
> ILK-7  371/372   364/372
> SNB 0  424/425   424/425
> IVB 0  545/546   545/546
> BYT 0  290/291   290/291
> HSW 0  579/579   579/579
> BDW 0  434/435   434/435
> 
> 
> > -Detailed-
> > test_platform: test_suite, test_case, result_with_drm_intel_nightly(count,
> machine_id...)...->result_with_patch_applied(count, machine_id)...
> > PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) ->
> PASS(4, M7)
> > PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) ->
> PASS(1, M7)
> > PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) -> PASS(1,
> M7)
> > PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) -> PASS(1,
> M7)
> > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank,
> DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(2, M26)PASS(2,
> M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible,
> DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3,
> M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible,
> PASS(4, M37M26) -> NSPT(1, M26)PASS(3, M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible,
> DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3,
> M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) ->
> DMESG_WARN(2, M26)PASS(2, M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, 
> > M37M26) ->
> DMESG_WARN(2, M26)PASS(2, M26)
> > ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, 
> > PASS(4,
> M37M26) -> DMESG_WARN(1, M26)PASS(3, M26)
> 
> And for this one:
> 
>   - it's not nessary to repeat the test suite name for every single row,
> if needed at all (I don't think it is when replying to kernel
> patches), it can be put beforehand.
[He, Shuang] this makes sense

>   - sorted by gen
>   - The machine id isn't useful in this report
[He, Shuang] Some time, test result diffs because of Machine have changed, 
machine id is put there to help understand the issue

>   - It'd be nice to add a some explanations on how to decipher the
> result column (what is the count, what the various states mean).
> Maybe after

Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0

[He, Shuang]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Monday, November 17, 2014 11:03 PM
> To: Lespiau, Damien
> Cc: He, Shuang; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for 
> eDP/DPLL0
> 
> On Sat, Nov 15, 2014 at 10:54:47AM +, Damien Lespiau wrote:
> > Hi Shuang,
> >
> > You wanted suggestions, so how about:
> >
> > For both examples, to determine the size of the column, I'd take the
> > length of the longest value of that column (including the title) and add
> > 4 to account for spacing. Left alignment for text, right alignement for
> > numbers (of course, all of that is debatable).
> >
> > On Fri, Nov 14, 2014 at 09:28:03PM -0800, shuang...@intel.com wrote:
> > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> > > -Summary-
> > > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
> > > BYT: pass/total=290/291->290/291
> > > PNV: pass/total=352/356->356/356
> > > ILK: pass/total=371/372->364/372
> > > IVB: pass/total=545/546->545/546
> > > SNB: pass/total=424/425->424/425
> > > HSW: pass/total=579/579->579/579
> > > BDW: pass/total=434/435->434/435
> >
> > For this one:
> >
> >   - a bit more spacing
> >   - some table-like alignment. That's assuming the mail client will use
> > monospaced fonts for text emails, it really should.
> >   - add the delta so it's easier to parse the interesting information
> 
> I think the delta should mention both + and - counts separately so that
> it's easy to see when a patch regressed the same amount of tests as it
> fixed. Iirc there's been a few cases before where this was important.
[He, Shuang] Agree with that, it's kind of like patch

Thanks
--Shuang
> 
> Otherwise I agree with damien, the column aligment and headers make the
> results a lot easier to read.
> -Daniel
> 
> >   - sort by gens
> >   - baseline_drm_intel_nightly_pass_rate can really just be
> > drm-intel-nightly
> >   - it's not just a single patch applied, so series applied?
> >
> > PlatformDeltadrm-intel-nightlySeries Applied
> > 
> > PNV+4  352/356   356/356
> > ILK-7  371/372   364/372
> > SNB 0  424/425   424/425
> > IVB 0  545/546   545/546
> > BYT 0  290/291   290/291
> > HSW 0  579/579   579/579
> > BDW 0  434/435   434/435
> >
> >
> > > -Detailed-
> > > test_platform: test_suite, test_case, result_with_drm_intel_nightly(count,
> machine_id...)...->result_with_patch_applied(count, machine_id)...
> > > PNV: Intel_gpu_tools, igt_gen3_mixed_blits, DMESG_WARN(1, M23) ->
> PASS(4, M7)
> > > PNV: Intel_gpu_tools, igt_gen3_render_mixed_blits, CRASH(1, M23) ->
> PASS(1, M7)
> > > PNV: Intel_gpu_tools, igt_gen3_render_tiledx_blits, CRASH(1, M23) ->
> PASS(1, M7)
> > > PNV: Intel_gpu_tools, igt_gen3_render_tiledy_blits, CRASH(1, M23) ->
> PASS(1, M7)
> > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-absolute-wf_vblank,
> DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(2, M26)PASS(2,
> M26)
> > > ILK: Intel_gpu_tools, 
> > > igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible,
> DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3,
> M26)
> > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-modeset-vs-hang-interruptible,
> PASS(4, M37M26) -> NSPT(1, M26)PASS(3, M26)
> > > ILK: Intel_gpu_tools, igt_kms_flip_flip-vs-wf_vblank-interruptible,
> DMESG_WARN(1, M26)PASS(3, M37M26) -> DMESG_WARN(1, M26)PASS(3,
> M26)
> > > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip, PASS(4, M37M26) ->
> DMESG_WARN(2, M26)PASS(2, M26)
> > > ILK: Intel_gpu_tools, igt_kms_flip_plain-flip-interruptible, PASS(4, 
> > > M37M26)
> -> DMESG_WARN(2, M26)PASS(2, M26)
> > > ILK: Intel_gpu_tools, igt_kms_flip_rcs-flip-vs-modeset-interruptible, 
> > > PASS(4,
> M37M26) -

Re: [Intel-gfx] [PATCH 9/9] drm/i915: Make all plane disables use

[He, Shuang]

No problem, I will add it

Thanks
--Shuang

> -Original Message-
> From: Lespiau, Damien
> Sent: Thursday, November 27, 2014 11:58 PM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 9/9] drm/i915: Make all plane disables use
> 
> Hi Shuang,
> 
> The threading is still broken in some MUAs. I believe we also need the
> References: header in addition to in-reply-to: to solve that.
> 
> HTH,
> 
> --
> Damien
> 
> On Mon, Nov 24, 2014 at 11:39:48PM -0800, shuang...@intel.com wrote:
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> > -Summary-
> > Platform  Delta  drm-intel-nightly  Series
> Applied
> > PNV -1  367/367
> 366/367
> > ILK -5  375/375  370/375
> > SNB -1  450/450
> 449/450
> > IVB -4  503/503
> 499/503
> > BYT  289/289
> 289/289
> > HSW -3  567/567
> 564/567
> > BDW  417/417
> 417/417
> > -Detailed-
> > Platform  Testdrm-intel-nightly
> Series Applied
> > *PNV  igt_gen3_mixed_blits  PASS(6, M23)  CRASH(1, M23)
> >  ILK  igt_gem_reset_stats_close-pending-fork-render  TIMEOUT(11,
> M37M26)PASS(1, M26)  TIMEOUT(1, M26)
> >  ILK  igt_kms_3d  DMESG_WARN(1, M26)PASS(3, M37M26)
> DMESG_WARN(1, M26)
> > *ILK  igt_kms_render_direct-render  PASS(4, M37M26)
> DMESG_WARN(1, M26)
> >  ILK  igt_kms_flip_rcs-flip-vs-modeset  DMESG_WARN(2, M26)PASS(1,
> M37)  DMESG_WARN(1, M26)
> >  ILK  igt_kms_flip_vblank-vs-hang  TIMEOUT(11, M37M26)PASS(1,
> M26)  TIMEOUT(1, M26)
> > *SNB  igt_kms_3d  PASS(2, M22M35)  DMESG_WARN(1, M35)
> >  IVB  igt_gem_bad_reloc_negative-reloc  NSPT(14,
> M34M21M4)PASS(1, M21)  NSPT(1, M21)
> >  IVB  igt_gem_bad_reloc_negative-reloc-lut  NSPT(3,
> M21M34M4)PASS(15, M21M34M4)  NSPT(1, M21)
> > *IVB  igt_kms_3d  PASS(2, M21)  DMESG_WARN(1, M21)
> > *IVB  igt_kms_cursor_crc_cursor-64x64-offscreen  PASS(2, M21)
> DMESG_WARN(1, M21)
> >  HSW  igt_gem_bad_reloc_negative-reloc-lut  NSPT(24,
> M40M20M19)PASS(1, M20)  NSPT(1, M19)
> > *HSW  igt_kms_rotation_crc_primary-rotation  PASS(23,
> M20M40M19)  DMESG_WARN(1, M19)
> > *HSW  igt_pm_rc6_residency_rc6-accuracy  PASS(25, M20M40M19)
> FAIL(1, M19)
> > Note: You need to pay more attention to line start with '*'
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PRTS] Kernel Patch testing [PATCH 10/10] drm/i915: Cache ringbuf pointer in

[He, Shuang]

From: Harrison, John C
Sent: Wednesday, December 10, 2014 9:06 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Cc: He, Shuang
Subject: Re: [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in

Is anyone else having problems reading the PRTS logs?
[He, Shuang] Hello, thanks for reporting back this issue


It looks like I got a merge failure complaint, presumably because I need to 
rebase to a newer nightly tree. However, the log file itself does not say 
anything useful. There is a bit of pre-amble which finishes by saying 'This 
file include 3 part: output, error and dmesg. The file opening is: 4260699.out' 
and then I get 13MB of repeated '' tags and that's it. Not a particularly 
useful log!
[He, Shuang] I can reproduce this issue, we'll fix the log, actually we haven't 
upload any log to the server for building kernel, so I think this is a bug for 
web UI for PRTS, we'll figure it out. And also we're figuring out better way to 
make it work for you. For example, the main issue here is that even we give you 
the failure and the baseline commit, you may not be able to find it in anywhere 
due to rebase of drm-intel-nightly tree, it will be still a pain for you to 
figure out what have happened. So the easiest way to have your patch finally 
applied to the baseline tree would be, we provide the exactly baseline commit 
and the link that you can pull in that commit, so you can simply rebase your 
patch to that specific commit, hence reduce the effort on both sides. And we're 
working to set up a place outside intel to hold those baseline commit.
Thanks
--Shuang

Also, why are the emails copied to 
'quarkon...@wo.com.cn<mailto:quarkon...@wo.com.cn>'?

On 09/12/2014 14:07, shuang...@intel.com<mailto:shuang...@intel.com> wrote:
Re:[PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: Cache 
ringbuf pointer in

Received the [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in mail(2014-12-09-22:10:10)

task_id(2014-12-09-22:10:10)

4212

user_id(2014-12-09-22:10:10)

53

user_name(2014-12-09-22:10:10)

Harrison

user_email(2014-12-09-22:10:10)

john.c.harri...@intel.com<mailto:john.c.harri...@intel.com>

task_result link(2014-12-09-22:10:10)

http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=4212


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

Re: [Intel-gfx] [PRTS] Kernel Patch testing [PATCH 10/10] drm/i915: Cache ringbuf pointer in

[He, Shuang]

From: Harrison, John C
Sent: Wednesday, December 10, 2014 9:06 PM
To: Intel-GFX@Lists.FreeDesktop.Org
Cc: He, Shuang
Subject: Re: [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in

Is anyone else having problems reading the PRTS logs?

It looks like I got a merge failure complaint, presumably because I need to 
rebase to a newer nightly tree. However, the log file itself does not say 
anything useful. There is a bit of pre-amble which finishes by saying 'This 
file include 3 part: output, error and dmesg. The file opening is: 4260699.out' 
and then I get 13MB of repeated '' tags and that's it. Not a particularly 
useful log!

Also, why are the emails copied to 
'quarkon...@wo.com.cn<mailto:quarkon...@wo.com.cn>'?
[He, Shuang] It's my personal push mail, I'll get short message on my mobile 
phone, when you send to that email. So basically I can check what's going on 
with my mobile phone. And take action accordingly, like this email did.

Thanks
   --Shuang


On 09/12/2014 14:07, shuang...@intel.com<mailto:shuang...@intel.com> wrote:
Re:[PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: Cache 
ringbuf pointer in

Received the [PRTS] Kernel Patch testing [Intel-gfx] [PATCH 10/10] drm/i915: 
Cache ringbuf pointer in mail(2014-12-09-22:10:10)

task_id(2014-12-09-22:10:10)

4212

user_id(2014-12-09-22:10:10)

53

user_name(2014-12-09-22:10:10)

Harrison

user_email(2014-12-09-22:10:10)

john.c.harri...@intel.com<mailto:john.c.harri...@intel.com>

task_result link(2014-12-09-22:10:10)

http://tinderbox.sh.intel.com/PRTS_UI/prtsresult.php?task_id=4212


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

Re: [Intel-gfx] intel_gpu_top missing clocks

[He, Shuang]

Hi, Chris
 Let’s put you to the correct Mailing list for this topic first

Thanks
 --Shuang
From: Chris Healy [mailto:cphe...@gmail.com]
Sent: Wednesday, June 18, 2014 1:15 AM
To: Eric Anholt; He, Shuang
Subject: intel_gpu_top missing clocks

Eric, Shuang,
I couldn't find an appropriate mailing list to report this on, so I'm mailing 
the two of you as you've both touched the clock code in intel_gpu_top.
I'm running an Ivy Bridge Mobile chipset and trying to use intel_gpu_top and 
intel_stepping to see the GPU clock frequencies.  In both cases, the clocks are 
"unknown".

When I look at the code, it seems that there's just no code path to handle this 
devid, though I'm not sure as I'm not very good at understanding code.  I see 
in intel_chipset.h that device id 0x0166 = PCI_CHIP_IVYBRIDGE_M_GT2 and that 
none of the "if's" in print_clock_info ultimately point to this device type.
Do either of you know why this would be?  Is it just a case of coding for the 
majority of chipset configurations?
If it's just the case of it not yet being handled, I'd be open to trying to add 
support for it if you could point me to the necessary chip documentation.
Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Initialize primary plane src/dst coords when reading hw state

[He, Shuang]

> -Original Message-
> From: Ander Conselvan de Oliveira [mailto:conselv...@gmail.com]
> Sent: Tuesday, January 13, 2015 4:34 PM
> To: Jani Nikula; He, Shuang; Gao, Ethan; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Initialize primary plane src/dst 
> coords
> when reading hw state
> 
> On 01/13/2015 10:17 AM, Jani Nikula wrote:
> >
> > Ander, please see if these results make sense.
> >
> > BR,
> > Jani.
> >
> > On Tue, 13 Jan 2015, shuang...@intel.com wrote:
> >> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> >> -Summary-
> >> Platform  Delta  drm-intel-nightly  Series
> Applied
> >> PNV -1  354/354
> 353/354
> >> ILK  201/201
> 201/201
> >> SNB  +1-1  401/424
> 401/424
> >> IVB -2  488/488
> 486/488
> >> BYT  278/278
> 278/278
> >> HSW -42  529/529
> 487/529
> >> BDW -1  405/405
> 404/405
> >> -Detailed-
> >> Platform  Test        drm-intel-nightly
> Series Applied
> >> *PNV  igt_gem_concurrent_blit_cpu-rcs-overwrite-source-interruptible
> PASS(2, M7)  NO_RESULT(1, M7)
> 
> I'm not sure of what to make out of NO_RESULT.
[He, Shuang] It means, we have tried to run it, but it didn't return any 
testing result (there are many possibility in this case: Test machine hung, for 
example)

> 
> >> *SNB  igt_gem_concurrent_blit_gtt-rcs-early-read-interruptible
> PASS(7, M35M22)  DMESG_WARN(1, M35)
[He, Shuang] Please use the one in *.out section which is recorded by piglit 
itself
"igt/gem_concurrent_blit/gtt-rcs-early-read-interruptible": { 
"dmesg": "[ 7857.565015] pci_pm_runtime_suspend(): 
intel_runtime_suspend+0x0/0x1bc [i915] returns -11
[ 7861.527641] pci_pm_runtime_suspend(): intel_runtime_suspend+0x0/0x1bc [i915] 
returns -11
[ 7895.526741] pci_pm_runtime_suspend(): intel_runtime_suspend+0x0/0x1bc [i915] 
returns -11
[ 7897.526694] pci_pm_runtime_suspend(): intel_runtime_suspend+0x0/0x1bc [i915] 
returns -11", 
"returncode": 0,

> 
> PRTS doesn't seem to have saved the dmesg for this one.
> 
> >> *IVB  igt_kms_plane_plane-panning-top-left-pipe-C-plane-2  PASS(2,
> M21M4)  DMESG_WARN(1, M4)
> 
> <3>[ 8370.823428] [drm:intel_set_pch_fifo_underrun_reporting [i915]]
> *ERROR* uncleared pch fifo underrun on pch transcoder C
> 
> >> *IVB  igt_kms_plane_plane-position-hole-pipe-C-plane-1  PASS(2,
> M21M4)  DMESG_WARN(1, M4)
> 
> <3>[ 8417.687721] [drm:intel_dp_start_link_train [i915]] *ERROR* too many
> voltage retries, give up
> <3>[ 8417.694032] [drm:intel_dp_start_link_train [i915]] *ERROR* too many
> voltage retries, give up
> <3>[ 8417.700334] [drm:intel_dp_start_link_train [i915]] *ERROR* too many
> voltage retries, give up
> <3>[ 8417.706640] [drm:intel_dp_start_link_train [i915]] *ERROR* too many
> voltage retries, give up
> <3>[ 8417.712947] [drm:intel_dp_start_link_train [i915]] *ERROR* too many
> voltage retries, give up
> <3>[ 8417.719256] [drm:intel_dp_start_link_train [i915]] *ERROR* too many
> voltage retries, give up
> <3>[ 8417.727057] [drm:intel_dp_complete_link_train [i915]] *ERROR* failed
> to train DP, aborting
> 
> >> *HSW  igt_gem_concurrent_blit_gttX-bcs-early-read-interruptible
> DMESG_WARN(2, M40)PASS(2, M20M19)  DMESG_WARN(1, M19)
> 
> It seems PRTS also forgot to save the dmesg for this one.
[He, Shuang] "igt/gem_concurrent_blit/gttX-bcs-early-read-interruptible": { 
"dmesg": "[ 8127.156781] pci_pm_runtime_suspend(): 
intel_runtime_suspend+0x0/0x1bc [i915] returns -11
[ 8135.168107] pci_pm_runtime_suspend(): intel_runtime_suspend+0x0/0x1bc [i915] 
returns -11
[ 8149.163954] pci_pm_runtime_suspend(): intel_runtime_suspend+0x0/0x1bc [i915] 
returns -11
[ 8151.178758] pci_pm_runtime_suspend(): intel_runtime_suspend+0x0/0x1bc [i915] 
returns -11",

Thanks
--Shuang
> 
> >> *BDW
> igt_gem_concurrent_blit_gtt-bcs-gpu-read-after-write-interruptible
> PASS(6, M30M28)  DMESG_WARN(1, M30)
> 
> <3>[ 7724.684295] [drm:hsw_unclaimed_reg_detect.isra.10 [i915]] *ERROR*
> Unclaimed register detected. Please use the i915.mmio_debug=1 to debug this
> problem.gem_concurrent_blit: starting subtest
> gtt-bcs-gpu-read-after-write-interruptible
> 
> Are any of those known issues?
> 
> Thanks,
> Ander
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Announce support for framebuffer modifiers

[He, Shuang]

Hello, this one is invalid report when debugging smarter patch apply method, in 
which case, baseline has id bigger than this task will generate invalidate 
comparison result.
I have fixed the comparison algorithm.
A correct one will be sent out later

Thanks
--Shuang

> -Original Message-
> From: He, Shuang
> Sent: Sunday, February 08, 2015 5:57 PM
> To: He, Shuang; Gao, Ethan; intel-gfx@lists.freedesktop.org;
> tvrtko.ursu...@linux.intel.com
> Subject: RE: [Intel-gfx] [PATCH 4/4] drm/i915: Announce support for
> framebuffer modifiers
> 
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> Task id: 5721
> -Summary-
> Platform  Delta  drm-intel-nightly  Series
> Applied
> PNV  283/283
> 283/283
> ILK  +1 308/319  309/319
> SNB  +23-1  319/346  341/346
> IVB  +2 376/384  378/384
> BYT  296/296
> 296/296
> HSW -1  425/428  424/428
> BDW  318/333
> 318/333
> -Detailed-
> Platform  Testdrm-intel-nightly
> Series Applied
>  ILK  igt_kms_flip_vblank-vs-hang  TIMEOUT(1, M37)PASS(1, M37)
> PASS(1, M37)
> *SNB  igt_kms_flip_dpms-vs-vblank-race  DMESG_WARN(2, M35M22)
> PASS(1, M22)
>  SNB  igt_kms_flip_modeset-vs-vblank-race-interruptible
> DMESG_WARN(1, M35)PASS(1, M22)  PASS(1, M22)
>  SNB  igt_kms_flip_single-buffer-flip-vs-dpms-off-vs-modeset-interruptible
> DMESG_WARN(1, M35)PASS(1, M22)  PASS(1, M22)
>  SNB  igt_kms_mmio_vs_cs_flip_setcrtc_vs_cs_flip  NSPT(1,
> M35)PASS(1, M22)  PASS(1, M22)
>  SNB  igt_kms_mmio_vs_cs_flip_setplane_vs_cs_flip  NSPT(1,
> M35)PASS(1, M22)  PASS(1, M22)
> *SNB  igt_kms_plane_plane-panning-bottom-right-pipe-B-plane-2
> PASS(2, M35M22)  TIMEOUT(1, M22)
>  SNB  igt_kms_rotation_crc_primary-rotation  NSPT(1, M35)PASS(1,
> M22)  PASS(1, M22)
>  SNB  igt_kms_rotation_crc_sprite-rotation  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_cursor  NSPT(1, M35)PASS(1, M22)  PASS(1,
> M22)
>  SNB  igt_pm_rpm_cursor-dpms  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_dpms-mode-unset-non-lpsp  NSPT(1, M35)PASS(1,
> M22)  PASS(1, M22)
>  SNB  igt_pm_rpm_dpms-non-lpsp  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_drm-resources-equal  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_fences  NSPT(1, M35)PASS(1, M22)  PASS(1,
> M22)
>  SNB  igt_pm_rpm_fences-dpms  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_gem-execbuf  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_gem-mmap-cpu  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_gem-mmap-gtt  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_gem-pread  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
> *SNB  igt_pm_rpm_i2c  FAIL(1, M22)NSPT(1, M35)  PASS(1, M22)
>  SNB  igt_pm_rpm_modeset-non-lpsp  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_modeset-non-lpsp-stress-no-wait  NSPT(1,
> M35)PASS(1, M22)  PASS(1, M22)
>  SNB  igt_pm_rpm_pci-d3-state  NSPT(1, M35)PASS(1, M22)
> PASS(1, M22)
>  SNB  igt_pm_rpm_rte  NSPT(1, M35)PASS(1, M22)  PASS(1, M22)
> *IVB  igt_gem_storedw_batches_loop_normal  DMESG_WARN(2, M34)
> PASS(1, M34)
>  IVB  igt_gem_storedw_batches_loop_secure-dispatch
> DMESG_WARN(1, M34)PASS(1, M34)  PASS(1, M34)
> *HSW  igt_gem_storedw_loop_blt  PASS(2, M40M20)
> DMESG_WARN(1, M20)
> Note: You need to pay more attention to line start with '*'
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make intel_pipe_has_type() and

[He, Shuang]

> -Original Message-
> From: He, Shuang
> Sent: Monday, October 20, 2014 10:15 PM
> To: He, Shuang; intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> Subject: RE: [Intel-gfx] [PATCH 4/4] drm/i915: Make intel_pipe_has_type() and
> 
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> -Summary-
> Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
> BYT: pass/total=271/271->269/271
> PNV: pass/total=269/271->270/271
> ILK: pass/total=3/3->3/3
[He, Shuang] This "3/3" result is not correct due to bug in PRTS system, I'll 
fix it

Thanks
--Shuang
> IVB: pass/total=271/271->271/271
> SNB: pass/total=271/271->271/271
> HSW: pass/total=271/271->271/271
> BDW: pass/total=271/271->269/271
> -Detailed-
> test_platform: test_suite, test_case,
> result_with_drm_intel_nightly->result_with_patch_applied
> BYT: Intel_gpu_tools,
> igt_gem_concurrent_blit_gttX-bcs-gpu-read-after-write-forked,
> PASS->TIMEOUT
> BYT: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc,
> PASS->DMESG_WARN
> PNV: Intel_gpu_tools,
> igt_gem_concurrent_blit_gtt-bcs-gpu-read-after-write-forked, TIMEOUT->PASS
> BDW: Intel_gpu_tools,
> igt_gem_concurrent_blit_gtt-bcs-gpu-read-after-write-forked, PASS->TIMEOUT
> BDW: Intel_gpu_tools,
> igt_gem_concurrent_blit_gttX-bcs-gpu-read-after-write-forked,
> PASS->TIMEOUT
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue items in

[He, Shuang]

> -Original Message-
> From: Daniel, Thomas
> Sent: Tuesday, October 21, 2014 8:46 PM
> To: Daniel Vetter; He, Shuang
> Cc: intel-gfx@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue items 
> in
> 
> 
> 
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, October 21, 2014 1:14 PM
> > To: He, Shuang
> > Cc: intel-gfx@lists.freedesktop.org; Daniel, Thomas
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/bdw: Clean up execlist queue
> > items in
> >
> > On Tue, Oct 21, 2014 at 01:32:44AM -0700, shuang...@intel.com wrote:
> > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> > > shuang...@intel.com)
> > > -Summary--
> > > ---
> > > PASS->TIMEOUT
> >
> > That's an awful lot of timeouts, especially since the code should only touch
> > bdw+. Has something gone south with prts hang recovery?
> > -Daniel
> Those results do look funky.
> The v1 patch won't boot without execlists anyway. V2 results are better.
[He, Shuang] PRTS hang recovery is working as expected here

Thanks
--Shuang
> 
> Thomas.
> 
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make intel_pipe_has_type() and

[He, Shuang]

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Tuesday, October 21, 2014 4:29 AM
> To: He, Shuang
> Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander
> Subject: Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make intel_pipe_has_type() and
> 
> On Mon, Oct 20, 2014 at 07:14:48AM -0700, shuang...@intel.com wrote:
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> > -Summary-
> > Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
> > BYT: pass/total=271/271->269/271
> > PNV: pass/total=269/271->270/271
> > ILK: pass/total=3/3->3/3
> > IVB: pass/total=271/271->271/271
> > SNB: pass/total=271/271->271/271
> > HSW: pass/total=271/271->271/271
> > BDW: pass/total=271/271->269/271
> > -Detailed-
> > test_platform: test_suite, test_case,
> result_with_drm_intel_nightly->result_with_patch_applied
> > BYT: Intel_gpu_tools,
> igt_gem_concurrent_blit_gttX-bcs-gpu-read-after-write-forked,
> PASS->TIMEOUT
> > BYT: Intel_gpu_tools, igt_kms_setmode_invalid-clone-single-crtc,
> PASS->DMESG_WARN
> > PNV: Intel_gpu_tools,
> igt_gem_concurrent_blit_gtt-bcs-gpu-read-after-write-forked, TIMEOUT->PASS
> > BDW: Intel_gpu_tools,
> igt_gem_concurrent_blit_gtt-bcs-gpu-read-after-write-forked, PASS->TIMEOUT
> > BDW: Intel_gpu_tools,
> igt_gem_concurrent_blit_gttX-bcs-gpu-read-after-write-forked,
> PASS->TIMEOUT
> 
> This smells a lot like flukes, since the patches really don't change
> functionality at all. Is there some way to filter out unstable testcases,
> or are these regressions real?
[He, Shuang] Yes, my next step is to work on do the 'dynamic subset test case' 
which will have some way to filter out unstable testcases, though it's based on 
history data, there may still have some leak

Thanks
--Shuang
> 
> In any case I've gone ahead and merged Ander's patches.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx