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

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

[Daniel Vetter]

This is a very similar bug in the load detect code fixed in

commit 9128b040eb774e04bc23777b005ace2b66ab2a85
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Mar 3 17:31:21 2015 +0100

    drm/i915: Fix modeset state confusion in the load detect code

But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
This is the version for -next. The one for -fixes just needs an
s/primary/intel_crtc->base.primary/ and some fudge in the diff. I just
want to apply this in both trees since with all the cherry-picking the
conflicts are fun already and with this patch in both places we can
just go with the code in -next.

Cheers, Daniel
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 
 		primary->fb = &plane_config->fb->base;
 		primary->state->crtc = &intel_crtc->base;
+		primary->crtc = &intel_crtc->base;
 		update_state_fb(primary);
 
 		return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 			drm_framebuffer_reference(c->primary->fb);
 			primary->fb = c->primary->fb;
 			primary->state->crtc = &intel_crtc->base;
+			primary->crtc = &intel_crtc->base;
 			update_state_fb(intel_crtc->base.primary);
 			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
 			break;
-- 
2.1.4

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

[Daniel Vetter]

This is a very similar bug in the load detect code fixed in

commit 9128b040eb774e04bc23777b005ace2b66ab2a85
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Mar 3 17:31:21 2015 +0100

    drm/i915: Fix modeset state confusion in the load detect code

But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
This is the version for -next. The one for -fixes just needs an
s/primary/intel_crtc->base.primary/ and some fudge in the diff. I just
want to apply this in both trees since with all the cherry-picking the
conflicts are fun already and with this patch in both places we can
just go with the code in -next.

Cheers, Daniel
---
 drivers/gpu/drm/i915/intel_display.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index ceb2e61b4c91..cb508542c6ab 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 
 		primary->fb = &plane_config->fb->base;
 		primary->state->crtc = &intel_crtc->base;
+		primary->crtc = &intel_crtc->base;
 		update_state_fb(primary);
 
 		return;
@@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
 			drm_framebuffer_reference(c->primary->fb);
 			primary->fb = c->primary->fb;
 			primary->state->crtc = &intel_crtc->base;
+			primary->crtc = &intel_crtc->base;
 			update_state_fb(intel_crtc->base.primary);
 			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
 			break;
-- 
2.1.4

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

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

[shuang.he]

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@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  Test                                drm-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_iTCO_vendor_support_snd_hda_codec_conexant_snd_hda_codec_generic_pcspkr_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_timer_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 '*'
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Daniel Vetter]

On Thu, Mar 26, 2015 at 02:53:10AM -0700, shuang.he@intel.com wrote:
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@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  Test                                drm-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_iTCO_vendor_support_snd_hda_codec_conexant_snd_hda_codec_generic_pcspkr_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_timer_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.
-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: [PATCH] drm/i915: Fixup legacy plane->crtc link for initial fb config

[He, Shuang]

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter@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.vetter@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.he@intel.com wrote:
> > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang.he@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  Test                                drm-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: [PATCH] drm/i915: Fixup legacy plane->crtc link for initial fb config

[Jani Nikula]

On Wed, 25 Mar 2015, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> This is a very similar bug in the load detect code fixed in
>
> commit 9128b040eb774e04bc23777b005ace2b66ab2a85
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Tue Mar 3 17:31:21 2015 +0100
>
>     drm/i915: Fix modeset state confusion in the load detect code
>
> But this time around it was the initial fb code that forgot to update
> the plane->crtc pointer. Otherwise it's the exact same bug, with the
> exact same restrains (any set_config call/ioctl that doesn't disable
> the pipe papers over the bug for free, so fairly hard to hit in normal
> testing). So if you want the full explanation just go read that one
> over there - it's rather long ...
>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Josh Boyer <jwboyer@fedoraproject.org>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> This is the version for -next. The one for -fixes just needs an
> s/primary/intel_crtc->base.primary/ and some fudge in the diff. I just
> want to apply this in both trees since with all the cherry-picking the
> conflicts are fun already and with this patch in both places we can
> just go with the code in -next.

I've also picked this up from -next to drm-intel-fixes.

BR,
Jani.


>
> Cheers, Daniel
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index ceb2e61b4c91..cb508542c6ab 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>  
>  		primary->fb = &plane_config->fb->base;
>  		primary->state->crtc = &intel_crtc->base;
> +		primary->crtc = &intel_crtc->base;
>  		update_state_fb(primary);
>  
>  		return;
> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>  			drm_framebuffer_reference(c->primary->fb);
>  			primary->fb = c->primary->fb;
>  			primary->state->crtc = &intel_crtc->base;
> +			primary->crtc = &intel_crtc->base;
>  			update_state_fb(intel_crtc->base.primary);
>  			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>  			break;
> -- 
> 2.1.4
>

-- 
Jani Nikula, Intel Open Source Technology Center

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

[Jani Nikula]

On Wed, 25 Mar 2015, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> This is a very similar bug in the load detect code fixed in
>
> commit 9128b040eb774e04bc23777b005ace2b66ab2a85
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Tue Mar 3 17:31:21 2015 +0100
>
>     drm/i915: Fix modeset state confusion in the load detect code
>
> But this time around it was the initial fb code that forgot to update
> the plane->crtc pointer. Otherwise it's the exact same bug, with the
> exact same restrains (any set_config call/ioctl that doesn't disable
> the pipe papers over the bug for free, so fairly hard to hit in normal
> testing). So if you want the full explanation just go read that one
> over there - it's rather long ...
>
> Cc: Matt Roper <matthew.d.roper@intel.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Josh Boyer <jwboyer@fedoraproject.org>
> Cc: Jani Nikula <jani.nikula@linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> This is the version for -next. The one for -fixes just needs an
> s/primary/intel_crtc->base.primary/ and some fudge in the diff. I just
> want to apply this in both trees since with all the cherry-picking the
> conflicts are fun already and with this patch in both places we can
> just go with the code in -next.

I've also picked this up from -next to drm-intel-fixes.

BR,
Jani.


>
> Cheers, Daniel
> ---
>  drivers/gpu/drm/i915/intel_display.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index ceb2e61b4c91..cb508542c6ab 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2594,6 +2594,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>  
>  		primary->fb = &plane_config->fb->base;
>  		primary->state->crtc = &intel_crtc->base;
> +		primary->crtc = &intel_crtc->base;
>  		update_state_fb(primary);
>  
>  		return;
> @@ -2627,6 +2628,7 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
>  			drm_framebuffer_reference(c->primary->fb);
>  			primary->fb = c->primary->fb;
>  			primary->state->crtc = &intel_crtc->base;
> +			primary->crtc = &intel_crtc->base;
>  			update_state_fb(intel_crtc->base.primary);
>  			obj->frontbuffer_bits |= INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe);
>  			break;
> -- 
> 2.1.4
>

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

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

[Daniel Vetter]

On Thu, Mar 26, 2015 at 11:08:00AM +0000, He, Shuang wrote:
> > -----Original Message-----
> > From: Daniel Vetter [mailto:daniel.vetter@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.vetter@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.he@intel.com wrote:
> > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> > shuang.he@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  Test                                drm-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).

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: [PATCH] drm/i915: Fixup legacy plane->crtc link for initial fb config

[He, Shuang]

> -----Original Message-----
> From: Daniel Vetter [mailto:daniel.vetter@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.vetter@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 +0000, He, Shuang wrote:
> > > -----Original Message-----
> > > From: Daniel Vetter [mailto:daniel.vetter@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.vetter@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.he@intel.com wrote:
> > > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> > > shuang.he@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  Test                                drm-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