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.
