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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/9/2023 01:38, Jani Nikula wrote:
On Fri, 06 Jan 2023, John Harrison <john.c.harrison@xxxxxxxxx> 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.






[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux