[PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Tvrtko Ursulin]

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Since pr_debug is not printed by default, change both test and subtest
log messages to pr_info so they are always logged.

Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
---
 drivers/gpu/drm/i915/selftests/i915_selftest.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 86c54ea37f48..0fa4501c4599 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -133,7 +133,7 @@ static int __run_selftests(const char *name,
 		if (signal_pending(current))
 			return -EINTR;
 
-		pr_debug(DRIVER_NAME ": Running %s\n", st->name);
+		pr_info(DRIVER_NAME ": Running %s\n", st->name);
 		if (data)
 			err = st->live(data);
 		else
@@ -209,7 +209,7 @@ int __i915_subtests(const char *caller,
 		if (signal_pending(current))
 			return -EINTR;
 
-		pr_debug(DRIVER_NAME ": Running %s/%s\n", caller, st->name);
+		pr_info(DRIVER_NAME ": Running %s/%s\n", caller, st->name);
 		GEM_TRACE("Running %s/%s\n", caller, st->name);
 
 		err = st->func(data);
-- 
2.19.1

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

Re: [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-11-20 17:28:39)
> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> 
> Since pr_debug is not printed by default, change both test and subtest
> log messages to pr_info so they are always logged.

I just use the trace... As when the test fails we say which subtest
failed, and hopefully include more details in the error message, and
recent history is in the trace dumped when considered relevant.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Tvrtko Ursulin]

On 20/11/2018 17:33, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-11-20 17:28:39)
>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>
>> Since pr_debug is not printed by default, change both test and subtest
>> log messages to pr_info so they are always logged.
> 
> I just use the trace... As when the test fails we say which subtest
> failed, and hopefully include more details in the error message, and
> recent history is in the trace dumped when considered relevant.

Fair. My thinking was simply to leave more breadcrumbs if the machine 
died in the middle of a subtest.

Regards,

Tvrtko

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

✓ Fi.CI.BAT: success for drm/i915/selftests: Log test and subtest names for easier debugging

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Log test and subtest names for easier debugging
URL   : https://patchwork.freedesktop.org/series/52774/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_5174 -> Patchwork_10866 =

== Summary - SUCCESS ==

  No regressions found.

  External URL: https://patchwork.freedesktop.org/api/1.0/series/52774/revisions/1/mbox/

== Known issues ==

  Here are the changes found in Patchwork_10866 that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@gem_ctx_switch@basic-default:
      fi-icl-u2:          PASS -> DMESG-WARN (fdo#107724)

    igt@i915_selftest@live_coherency:
      fi-gdg-551:         PASS -> DMESG-FAIL (fdo#107164)

    igt@i915_selftest@live_hangcheck:
      fi-bwr-2160:        PASS -> DMESG-FAIL (fdo#108735)

    
    ==== Possible fixes ====

    igt@gem_exec_suspend@basic-s3:
      fi-icl-u2:          DMESG-WARN (fdo#107724) -> PASS

    igt@i915_selftest@live_execlists:
      fi-apl-guc:         DMESG-WARN (fdo#108622) -> PASS

    igt@kms_flip@basic-flip-vs-dpms:
      fi-skl-6700hq:      DMESG-WARN (fdo#105998) -> PASS

    
  fdo#105998 https://bugs.freedesktop.org/show_bug.cgi?id=105998
  fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
  fdo#107724 https://bugs.freedesktop.org/show_bug.cgi?id=107724
  fdo#108622 https://bugs.freedesktop.org/show_bug.cgi?id=108622
  fdo#108735 https://bugs.freedesktop.org/show_bug.cgi?id=108735


== Participating hosts (52 -> 46) ==

  Missing    (6): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-u3 


== Build changes ==

    * Linux: CI_DRM_5174 -> Patchwork_10866

  CI_DRM_5174: 0bfa7192170c039a271ebc27222b4b91516e73f6 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4722: fdcdfa1e220c5070072d5dac9523cd105e7406c2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10866: 892a393cb77f0051624d17df57e5d53c3ca43ead @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

892a393cb77f drm/i915/selftests: Log test and subtest names for easier debugging

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10866/issues.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-11-20 17:58:33)
> 
> On 20/11/2018 17:33, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-11-20 17:28:39)
> >> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>
> >> Since pr_debug is not printed by default, change both test and subtest
> >> log messages to pr_info so they are always logged.
> > 
> > I just use the trace... As when the test fails we say which subtest
> > failed, and hopefully include more details in the error message, and
> > recent history is in the trace dumped when considered relevant.
> 
> Fair. My thinking was simply to leave more breadcrumbs if the machine 
> died in the middle of a subtest.

Thinking more about it, the easiest option would be to actually enable
pr_debug, iirc a config option.

However, the only time we don't get breadcrumbs is if the machine
spontaneously combusts, which we are told is a mere figment of our
imagination.  Most often I wonder if we simply do not get the death
throes - adding logging won't help if we don't capture it. For the true
spontaneous combustion, it's pretty random and all I can think of
suggesting are more sanity checks to try and catch inconsistencies early.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Tvrtko Ursulin]

On 20/11/2018 18:10, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-11-20 17:58:33)
>>
>> On 20/11/2018 17:33, Chris Wilson wrote:
>>> Quoting Tvrtko Ursulin (2018-11-20 17:28:39)
>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>
>>>> Since pr_debug is not printed by default, change both test and subtest
>>>> log messages to pr_info so they are always logged.
>>>
>>> I just use the trace... As when the test fails we say which subtest
>>> failed, and hopefully include more details in the error message, and
>>> recent history is in the trace dumped when considered relevant.
>>
>> Fair. My thinking was simply to leave more breadcrumbs if the machine
>> died in the middle of a subtest.
> 
> Thinking more about it, the easiest option would be to actually enable
> pr_debug, iirc a config option.

AFAICT we would need to pass -DDEBUG to interesting compilation units.

> However, the only time we don't get breadcrumbs is if the machine
> spontaneously combusts, which we are told is a mere figment of our
> imagination.  Most often I wonder if we simply do not get the death
> throes - adding logging won't help if we don't capture it. For the true
> spontaneous combustion, it's pretty random and all I can think of
> suggesting are more sanity checks to try and catch inconsistencies early.

Well I was looking at one such log today so hence the patch.. :)

<6>[  491.437102] i915: Performing live selftests with st_random_seed=0x3bd88daf st_timeout=1000
<7>[  491.438062] [drm:intel_power_well_enable [i915]] enabling always-on
<7>[  491.438121] [drm:intel_power_well_enable [i915]] enabling DC off
<7>[  491.438509] [drm:gen9_set_dc_state [i915]] Setting DC state from 02 to 00
<7>[  491.541663] [drm:intel_power_well_disable [i915]] disabling DC off
<7>[  491.541722] [drm:skl_enable_dc6 [i915]] Enabling DC6
<7>[  491.541751] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02
<7>[  491.542180] [drm:intel_power_well_disable [i915]] disabling always-on
<7>[  495.443505] [drm:intel_power_well_enable [i915]] enabling always-on
<7>[  495.443533] [drm:intel_power_well_enable [i915]] enabling DC off
<7>[  495.443817] [drm:gen9_set_dc_state [i915]] Setting DC state from 02 to 00
<7>[  499.549369] [drm:intel_power_well_disable [i915]] disabling DC off
<7>[  499.549403] [drm:skl_enable_dc6 [i915]] Enabling DC6
<7>[  499.549431] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02
<7>[  499.549863] [drm:intel_power_well_disable [i915]] disabling always-on
<6>[  500.448268] i915_reset_engine(rcs0:idle): 265564 resets
<6>[  501.449250] i915_reset_engine(bcs0:idle): 249487 resets
EOF

I can certainly send a patch for -DDEBUG, seems like that would be the
correct thing to do for all selftests.

Regards,

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

Re: [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-11-20 18:18:00)
> 
> On 20/11/2018 18:10, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-11-20 17:58:33)
> >>
> >> On 20/11/2018 17:33, Chris Wilson wrote:
> >>> Quoting Tvrtko Ursulin (2018-11-20 17:28:39)
> >>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> >>>>
> >>>> Since pr_debug is not printed by default, change both test and subtest
> >>>> log messages to pr_info so they are always logged.
> >>>
> >>> I just use the trace... As when the test fails we say which subtest
> >>> failed, and hopefully include more details in the error message, and
> >>> recent history is in the trace dumped when considered relevant.
> >>
> >> Fair. My thinking was simply to leave more breadcrumbs if the machine
> >> died in the middle of a subtest.
> > 
> > Thinking more about it, the easiest option would be to actually enable
> > pr_debug, iirc a config option.
> 
> AFAICT we would need to pass -DDEBUG to interesting compilation units.
> 
> > However, the only time we don't get breadcrumbs is if the machine
> > spontaneously combusts, which we are told is a mere figment of our
> > imagination.  Most often I wonder if we simply do not get the death
> > throes - adding logging won't help if we don't capture it. For the true
> > spontaneous combustion, it's pretty random and all I can think of
> > suggesting are more sanity checks to try and catch inconsistencies early.
> 
> Well I was looking at one such log today so hence the patch.. :)

But given the number of unexplained skl lockups, looking at a sporadic
(if not one off) example as opposed to say gem_cpu_reloc which kills
shard-skl every time seems like hunting in the dark.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for drm/i915/selftests: Log test and subtest names for easier debugging

[Patchwork]

== Series Details ==

Series: drm/i915/selftests: Log test and subtest names for easier debugging
URL   : https://patchwork.freedesktop.org/series/52774/
State : success

== Summary ==

= CI Bug Log - changes from CI_DRM_5174_full -> Patchwork_10866_full =

== Summary - WARNING ==

  Minor unknown changes coming with Patchwork_10866_full need to be verified
  manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_10866_full, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  

== Possible new issues ==

  Here are the unknown changes that may have been introduced in Patchwork_10866_full:

  === IGT changes ===

    ==== Warnings ====

    igt@pm_rc6_residency@rc6-accuracy:
      shard-snb:          SKIP -> PASS

    
== Known issues ==

  Here are the changes found in Patchwork_10866_full that come from known issues:

  === IGT changes ===

    ==== Issues hit ====

    igt@kms_chv_cursor_fail@pipe-a-128x128-top-edge:
      shard-skl:          NOTRUN -> FAIL (fdo#104671) +1

    igt@kms_cursor_crc@cursor-256x85-onscreen:
      shard-apl:          PASS -> FAIL (fdo#103232) +1

    igt@kms_fbcon_fbt@psr:
      shard-skl:          NOTRUN -> FAIL (fdo#107882)

    igt@kms_flip@plain-flip-ts-check:
      shard-skl:          PASS -> FAIL (fdo#100368)

    igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-indfb-draw-mmap-wc:
      shard-skl:          NOTRUN -> FAIL (fdo#103167) +2

    igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
      shard-glk:          PASS -> FAIL (fdo#103167)

    igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-blt:
      shard-skl:          NOTRUN -> FAIL (fdo#105682)

    igt@kms_frontbuffer_tracking@fbcpsr-rgb101010-draw-render:
      shard-skl:          NOTRUN -> FAIL (fdo#103167, fdo#105682)

    igt@kms_plane@pixel-format-pipe-c-planes:
      shard-glk:          PASS -> FAIL (fdo#103166)

    igt@kms_plane@plane-position-covered-pipe-a-planes:
      shard-skl:          NOTRUN -> FAIL (fdo#103166)

    igt@kms_plane_alpha_blend@pipe-a-alpha-7efc:
      shard-skl:          NOTRUN -> FAIL (fdo#108145, fdo#107815) +2

    igt@kms_universal_plane@universal-plane-pipe-a-functional:
      shard-apl:          PASS -> FAIL (fdo#103166)

    
    ==== Possible fixes ====

    igt@kms_cursor_crc@cursor-256x85-sliding:
      shard-apl:          FAIL (fdo#103232) -> PASS +1

    igt@kms_cursor_legacy@2x-nonblocking-modeset-vs-cursor-atomic:
      shard-glk:          FAIL (fdo#105454, fdo#106509) -> PASS

    igt@kms_cursor_legacy@cursora-vs-flipa-toggle:
      shard-glk:          DMESG-WARN (fdo#106538, fdo#105763) -> PASS

    igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
      shard-glk:          FAIL (fdo#103166) -> PASS

    igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
      shard-apl:          FAIL (fdo#103166) -> PASS

    igt@kms_setmode@basic:
      shard-kbl:          FAIL (fdo#99912) -> PASS

    
    ==== Warnings ====

    igt@kms_content_protection@legacy:
      shard-apl:          FAIL (fdo#108597) -> INCOMPLETE (fdo#103927)

    
  fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
  fdo#103166 https://bugs.freedesktop.org/show_bug.cgi?id=103166
  fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
  fdo#103232 https://bugs.freedesktop.org/show_bug.cgi?id=103232
  fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927
  fdo#104671 https://bugs.freedesktop.org/show_bug.cgi?id=104671
  fdo#105454 https://bugs.freedesktop.org/show_bug.cgi?id=105454
  fdo#105682 https://bugs.freedesktop.org/show_bug.cgi?id=105682
  fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763
  fdo#106509 https://bugs.freedesktop.org/show_bug.cgi?id=106509
  fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538
  fdo#107815 https://bugs.freedesktop.org/show_bug.cgi?id=107815
  fdo#107882 https://bugs.freedesktop.org/show_bug.cgi?id=107882
  fdo#108145 https://bugs.freedesktop.org/show_bug.cgi?id=108145
  fdo#108597 https://bugs.freedesktop.org/show_bug.cgi?id=108597
  fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912


== Participating hosts (7 -> 6) ==

  Missing    (1): shard-iclb 


== Build changes ==

    * Linux: CI_DRM_5174 -> Patchwork_10866

  CI_DRM_5174: 0bfa7192170c039a271ebc27222b4b91516e73f6 @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_4722: fdcdfa1e220c5070072d5dac9523cd105e7406c2 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_10866: 892a393cb77f0051624d17df57e5d53c3ca43ead @ git://anongit.freedesktop.org/gfx-ci/linux
  piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10866/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Tvrtko Ursulin]

On 20/11/2018 18:18, Tvrtko Ursulin wrote:
> 
> On 20/11/2018 18:10, Chris Wilson wrote:
>> Quoting Tvrtko Ursulin (2018-11-20 17:58:33)
>>>
>>> On 20/11/2018 17:33, Chris Wilson wrote:
>>>> Quoting Tvrtko Ursulin (2018-11-20 17:28:39)
>>>>> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>>>>>
>>>>> Since pr_debug is not printed by default, change both test and subtest
>>>>> log messages to pr_info so they are always logged.
>>>>
>>>> I just use the trace... As when the test fails we say which subtest
>>>> failed, and hopefully include more details in the error message, and
>>>> recent history is in the trace dumped when considered relevant.
>>>
>>> Fair. My thinking was simply to leave more breadcrumbs if the machine
>>> died in the middle of a subtest.
>>
>> Thinking more about it, the easiest option would be to actually enable
>> pr_debug, iirc a config option.
> 
> AFAICT we would need to pass -DDEBUG to interesting compilation units.
> 
>> However, the only time we don't get breadcrumbs is if the machine
>> spontaneously combusts, which we are told is a mere figment of our
>> imagination.  Most often I wonder if we simply do not get the death
>> throes - adding logging won't help if we don't capture it. For the true
>> spontaneous combustion, it's pretty random and all I can think of
>> suggesting are more sanity checks to try and catch inconsistencies early.
> 
> Well I was looking at one such log today so hence the patch.. :)
> 
> <6>[  491.437102] i915: Performing live selftests with st_random_seed=0x3bd88daf st_timeout=1000
> <7>[  491.438062] [drm:intel_power_well_enable [i915]] enabling always-on
> <7>[  491.438121] [drm:intel_power_well_enable [i915]] enabling DC off
> <7>[  491.438509] [drm:gen9_set_dc_state [i915]] Setting DC state from 02 to 00
> <7>[  491.541663] [drm:intel_power_well_disable [i915]] disabling DC off
> <7>[  491.541722] [drm:skl_enable_dc6 [i915]] Enabling DC6
> <7>[  491.541751] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02
> <7>[  491.542180] [drm:intel_power_well_disable [i915]] disabling always-on
> <7>[  495.443505] [drm:intel_power_well_enable [i915]] enabling always-on
> <7>[  495.443533] [drm:intel_power_well_enable [i915]] enabling DC off
> <7>[  495.443817] [drm:gen9_set_dc_state [i915]] Setting DC state from 02 to 00
> <7>[  499.549369] [drm:intel_power_well_disable [i915]] disabling DC off
> <7>[  499.549403] [drm:skl_enable_dc6 [i915]] Enabling DC6
> <7>[  499.549431] [drm:gen9_set_dc_state [i915]] Setting DC state from 00 to 02
> <7>[  499.549863] [drm:intel_power_well_disable [i915]] disabling always-on
> <6>[  500.448268] i915_reset_engine(rcs0:idle): 265564 resets
> <6>[  501.449250] i915_reset_engine(bcs0:idle): 249487 resets
> EOF
> 
> I can certainly send a patch for -DDEBUG, seems like that would be the
> correct thing to do for all selftests.

I've changed my mind - I think it is more desirable to actually just do 
what this patch did and convert test start messages to pr_info.

To enable all pr_debug by default, even if compiled with i915 debugging 
on, doesn't seem conceptually correct. There might be ones which are 
prohibitively noisy and in any case it would defeat the point of dynamic 
debug.

Regards,

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

Re: [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-11-21 09:02:18)
> 
> On 20/11/2018 18:18, Tvrtko Ursulin wrote:
> > I can certainly send a patch for -DDEBUG, seems like that would be the
> > correct thing to do for all selftests.
> 
> I've changed my mind - I think it is more desirable to actually just do 
> what this patch did and convert test start messages to pr_info.
> 
> To enable all pr_debug by default, even if compiled with i915 debugging 
> on, doesn't seem conceptually correct. There might be ones which are 
> prohibitively noisy and in any case it would defeat the point of dynamic 
> debug.

Nah, I still consider this to be test infra debug noise, and pr_debug()
quite apt for describing that.

And for the task you have, nothing more than a wild goose chase.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915/selftests: Log test and subtest names for easier debugging

[Tvrtko Ursulin]

On 21/11/2018 09:33, Chris Wilson wrote:
> Quoting Tvrtko Ursulin (2018-11-21 09:02:18)
>>
>> On 20/11/2018 18:18, Tvrtko Ursulin wrote:
>>> I can certainly send a patch for -DDEBUG, seems like that would be the
>>> correct thing to do for all selftests.
>>
>> I've changed my mind - I think it is more desirable to actually just do
>> what this patch did and convert test start messages to pr_info.
>>
>> To enable all pr_debug by default, even if compiled with i915 debugging
>> on, doesn't seem conceptually correct. There might be ones which are
>> prohibitively noisy and in any case it would defeat the point of dynamic
>> debug.
> 
> Nah, I still consider this to be test infra debug noise, and pr_debug()
> quite apt for describing that.

Shrug. A few lines in the see of noise, I don't see any harm but just 
bringing it to the same state as IGT run logs.

> And for the task you have, nothing more than a wild goose chase.

That one has been parked for now, these are all just after effects.

Regards,

Tvrtko

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