From: Matthew Brost <matthew.brost@intel.com>
To: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: intel-xe@lists.freedesktop.org, Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: Re: [PATCH] drm/xe: Do not flood dmesg with guc log
Date: Thu, 18 Jan 2024 19:10:27 +0000 [thread overview]
Message-ID: <Zal3oznvaamLHv6x@DUT025-TGLU.fm.intel.com> (raw)
In-Reply-To: <osoxittwh6wna5rq3awbvzddqp6dsggbxg5xrfgcmft3bcut6x@y4vfqvgb4kw5>
On Thu, Jan 18, 2024 at 12:16:27PM -0600, Lucas De Marchi wrote:
> On Thu, Jan 18, 2024 at 09:31:09AM -0500, Rodrigo Vivi wrote:
> > On Wed, Jan 17, 2024 at 05:42:00PM -0600, Lucas De Marchi wrote:
> > > On Wed, Jan 17, 2024 at 03:40:59PM -0500, Rodrigo Vivi wrote:
> > > > This information is already present at
> > > > /sys/kernel/debug/dri/0/gt0/uc/guc_log if needed.
> > >
> > > but is it persisted if we couldn't load guc?
> >
> > well, it was there here with the same content that was spit to dmesg.
> > Maybe just because I got this after a resume?
>
> not sure. I remember past debugs I had to rely on the guc log being
> relayed to to kernel log when debugging issues on the golden LRC
> submission. Honestly I don't remember if that was with i915 or xe.
>
> commit 4bc3a34f1237 ("drm/xe: Dump GuC log to dmesg on load / auth failure")
> seems to be the one adding it before drm-xe-next creation, but maybe
> we just didn't have a better alternative at the time.
>
> >
> > If so I would still prefer to make that persistent instead
> > of the flooded dmesg that gets really messed up and hard
> > to navigate to find the real useful information of the
> > failures.
>
> that would be my preference too. If it works, I'm fine with that. At
> least the end user should never be exposed to that amount of info we
> print.
>
> could we add the guc log to a devcoredump if we failed earlier?
>
I agree that if we can avoid flooding dmesg either via debugfs being
available or creating a devcoredump that is the preference.
I added this code originally to debug failures on driver load during
early Xe bring up. I haven't used this in a very long time.
Matt
> Lucas De Marchi
>
> >
> > >
> > > >
> > > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> > > > ---
> > > > drivers/gpu/drm/xe/xe_guc.c | 1 -
> > > > 1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> > > > index 235d27b17ff99..2a71348c5deda 100644
> > > > --- a/drivers/gpu/drm/xe/xe_guc.c
> > > > +++ b/drivers/gpu/drm/xe/xe_guc.c
> > > > @@ -466,7 +466,6 @@ static int guc_wait_ucode(struct xe_guc *guc)
> > > > ret = -ENXIO;
> > > > }
> > > >
> > >
> > > trailing newline above
> >
> > not actually a newline, but I can remove that extra line there
> > while removing this.
> > Wonder if I also should remove the spaces between the if/else
> > above this block as well... The "style" there looked strange,
> > but I decided to not touch.
> >
> > >
> > > Lucas De Marchi
> > >
> > > > - xe_guc_log_print(&guc->log, &p);
> > > > } else {
> > > > drm_dbg(&xe->drm, "GuC successfully loaded");
> > > > }
> > > > --
> > > > 2.43.0
> > > >
next prev parent reply other threads:[~2024-01-18 19:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 20:40 [PATCH] drm/xe: Do not flood dmesg with guc log Rodrigo Vivi
2024-01-17 21:11 ` Rodrigo Vivi
2024-01-17 23:42 ` Lucas De Marchi
2024-01-18 14:31 ` Rodrigo Vivi
2024-01-18 18:16 ` Lucas De Marchi
2024-01-18 19:10 ` Matthew Brost [this message]
2024-01-18 20:58 ` Lucas De Marchi
2024-01-18 21:46 ` Rodrigo Vivi
2024-01-18 21:48 ` Rodrigo Vivi
2024-01-19 0:00 ` Lucas De Marchi
2024-01-18 2:10 ` ✓ CI.Patch_applied: success for drm/xe: Do not flood dmesg with guc log (rev2) Patchwork
2024-01-18 2:10 ` ✓ CI.checkpatch: " Patchwork
2024-01-18 2:11 ` ✓ CI.KUnit: " Patchwork
2024-01-18 2:18 ` ✓ CI.Build: " Patchwork
2024-01-18 2:19 ` ✓ CI.Hooks: " Patchwork
2024-01-18 2:20 ` ✓ CI.checksparse: " Patchwork
2024-01-18 2:43 ` ✓ CI.BAT: " Patchwork
2024-01-18 21:52 ` ✓ CI.Patch_applied: success for drm/xe: Do not flood dmesg with guc log (rev3) Patchwork
2024-01-18 21:52 ` ✓ CI.checkpatch: " Patchwork
2024-01-18 21:53 ` ✓ CI.KUnit: " Patchwork
2024-01-18 22:00 ` ✓ CI.Build: " Patchwork
2024-01-18 22:00 ` ✓ CI.Hooks: " Patchwork
2024-01-18 22:02 ` ✓ CI.checksparse: " Patchwork
2024-01-18 22:26 ` ✓ CI.BAT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Zal3oznvaamLHv6x@DUT025-TGLU.fm.intel.com \
--to=matthew.brost@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=lucas.demarchi@intel.com \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox