Re: [Intel-gfx] [PATCH v2 4/5] drm/i915/guc: Add GuC CT specific debug print wrappers

[John Harrison <john.c.harrison@intel.com>]

On 1/9/2023 01:38, Jani Nikula wrote:
> On Fri, 06 Jan 2023, John Harrison <john.c.harrison@intel.com> wrote:
>> On 12/6/2022 03:06, Tvrtko Ursulin wrote:
>>> On 05/12/2022 18:44, Michal Wajdeczko wrote:
>>>> On 05.12.2022 14:16, Tvrtko Ursulin wrote:
>>>>> On 02/12/2022 20:14, John Harrison wrote:
>>>>> [snip]
>>>>>
>>>>>> Random meaningless (to me) message that is apparently a display thing:
>>>>>> drm_dbg_kms(&dev_priv->drm, "disabling %s\n", pll->info->name);
>>>>>> i915 0000:00:02.0: [drm:intel_disable_shared_dpll [i915]] disabling
>>>>>> PORT PLL B
>>>>> Plan is to not touch outside gt/.
>> For some unexplicable reason that means it is almost impossible to see
>> the actual problems in most CI dmesg logs because they are swamped with
>> irrelevant display messages that cannot be filtered out. For example, I
>> recently manually grep'd out all the display spam from a bug report log.
>> The dmesg file went from 12MB to 700KB. That is a significant problem
>> that makes bug triage way harder than it needs to be.
> You can adjust drm.debug module parameter to get rid of almost all
> display debugs. They're logged using the appropriate debug categories.
No, you can't. See above comment about 'most CI dmesg logs'. This is 
when trying to triage bugs created by the CI systems. In that case, the 
log already exists and it was generated at full debug and it is tens if 
not hundreds of MBs in size. And there is no single tag attached to the 
display messages to run 'grep -v' on. They are just a random collection 
of disparate function names.

John.

>
>
> BR,
> Jani.
>
>