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 shuang...@intel.com 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
-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 shuang...@intel.com 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 20/20] drm/i915: Enable skylake sprite plane scaling using shared scalers
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] drm: Kernel Crash in drm_unlock
-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] drm/i915: Fixup legacy plane-crtc link for initial fb config
-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
-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 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. I don't mean automatic judgement, I just want to know whether the dmesg splat in the mail is with the patch or without. In this case both nightly and with the series applied there was a DMESG_WARN, so I can't tell whether the dmesg noise is the old one (no problem) or the same one (no problem) or a new kind of dmesg new (needs action). [He, Shuang] Oh, I see, it is for new result (With patch applied). I will add some indicator for that. Thanks --Shuang I don't expect the script to do that decision for me. -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 i-g-t 1/2 v2] lib: Add media spin
(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 jeff.mc...@intel.com
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 jeff.mc...@intel.com
---
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 i915_drm.h
@@ -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. Each spin
+ * increments a counter whose final 32-bit value is written to the
+ * destination buffer on completion. This utility provides a simple way
+ * to keep the render engine busy for a set time for various tests.
+ */
+typedef void (*igt_media_spinfunc_t)(struct intel_batchbuffer *batch,
+ struct igt_buf *dst, uint32_t spins);
+
+igt_media_spinfunc_t igt_get_media_spinfunc(int
Re: [Intel-gfx] [PATCH] drm/i195/bxt: Add A1 stepping for Broxton
-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 4/4] drm/i915: Announce support for framebuffer modifiers
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] drm/i915: Initialize primary plane src/dst coords when reading hw state
-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 Testdrm-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] [PRTS] Kernel Patch testing [PATCH 10/10] drm/i915: Cache ringbuf pointer in
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 'br' 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.cnmailto:quarkon...@wo.com.cn'? On 09/12/2014 14:07, shuang...@intel.commailto: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.commailto: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
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 'br' tags and that's it. Not a particularly useful log! Also, why are the emails copied to 'quarkon...@wo.com.cnmailto: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.commailto: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.commailto: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] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0
-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 the table as it only needs to be read a few times to get it. [He, Shuang] yes, it may help. I'm always be hesitating on how to put these things in the right position. I'll see if your way could help PlatformTest drm-intel-nightlySeries Applied --- ILK igt_kms_flip_flip-vs-absolute-wf_vblank DMESG_WARN(1) PASS(3)DMESG_WARN(2) PASS(2) ILK igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible DMESG_WARN(1) PASS(3)DMESG_WARN(1) PASS(3) .. HTH
Re: [Intel-gfx] [PATCH 4/4] drm/i915/skl: Read out crtl1 for eDP/DPLL0
-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) - 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. - sorted by gen - The machine id isn't useful in this report - 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 the table as it only needs to be read a few times to get it. PlatformTest drm-intel-nightlySeries Applied --- ILK igt_kms_flip_flip-vs-absolute-wf_vblank DMESG_WARN(1) PASS(3)DMESG_WARN(2) PASS(2) ILK igt_kms_flip_flip-vs-absolute-wf_vblank-interruptible DMESG_WARN(1) PASS(3)DMESG_WARN(1) PASS(3
Re: [Intel-gfx] [PATCH] drm/i915: Delete outdated comment in
-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-579/579 BDW: pass/total=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)... BYT: Intel_gpu_tools, igt_gem_userptr_blits_forked-sync-swapping-multifd-mempressure-interruptib le, PASS(4
[Intel-gfx] [Announcement] PRTS is now enabled for Intel-gfx for Kernel patch testing
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 shuang...@intel.commailto: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/bdw: Clean up execlist queue items in
-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
-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
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Make intel_pipe_has_type() and
-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] intel_gpu_top missing clocks
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] The whole round of i-g-t testing cost too long running time
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 77474https://bugs.freedesktop.org/show_bug.cgi?id=77474 - [PNV/IVB/HSW]igt/gem_tiled_swapping is slow and Bug 77475https://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+. 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
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 77474https://bugs.freedesktop.org/show_bug.cgi?id=77474 - [PNV/IVB/HSW]igt/gem_tiled_swapping is slow and Bug 77475https://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. ThomasI 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
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 shuang...@intel.com
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 shuang...@intel.com
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
---
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/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1188,6 +1188,32 @@ static void dp_aux_irq_handler(struct drm_device
*dev)
wake_up_all(dev_priv-gmbus_wait_queue);
}
+#if defined(CONFIG_DEBUG_FS)
+static void ivb_pipe_crc_update(struct drm_device *dev, enum pipe pipe)
+{
+ struct drm_i915_private *dev_priv = dev-dev_private;
+ struct intel_pipe_crc *pipe_crc = dev_priv-pipe_crc[pipe];
+ struct intel_pipe_crc_entry *entry;
+ ktime_t now;
+ int ts, slot;
+
+ now = ktime_get();
+ ts = ktime_to_us(now);
+
+ slot = (atomic_read(pipe_crc-slot) + 1
