Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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
> > > >

  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