On Thu, Mar 26, 2015 at 11:08:00AM +0000, He, Shuang wrote: > > -----Original Message----- > > From: Daniel Vetter [mailto:daniel.vetter@xxxxxxxx] On Behalf Of Daniel > > Vetter > > Sent: Thursday, March 26, 2015 6:24 PM > > To: He, Shuang > > Cc: Gao, Ethan; intel-gfx@xxxxxxxxxxxxxxxxxxxxx; daniel.vetter@xxxxxxxx > > Subject: Re: [PATCH] drm/i915: Fixup legacy plane->crtc link for > > initial fb config > > > > On Thu, Mar 26, 2015 at 02:53:10AM -0700, shuang.he@xxxxxxxxx wrote: > > > Tested-By: PRC QA PRTS (Patch Regression Test System Contact: > > shuang.he@xxxxxxxxx) > > > 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
