All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>,
	<intel-xe@lists.freedesktop.org>
Cc: <daniele.ceraolospurio@intel.com>, <aravind.iddamsetty@intel.com>,
	<mallesh.koujalagi@intel.com>,
	<alan.previn.teres.alexis@intel.com>, <julia.filipchuk@intel.com>
Subject: Re: [PATCH v2 4/5] drm/xe/guc: Report major GuC failures using SIGID
Date: Wed, 2 Sep 2026 16:33:52 +0200	[thread overview]
Message-ID: <00e3acce-3f21-4aad-a5d8-749e26bf7b2d@intel.com> (raw)
In-Reply-To: <20260901211204.131972-11-umesh.nerlige.ramappa@intel.com>



On 9/1/2026 11:12 PM, Umesh Nerlige Ramappa wrote:
> From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> 
> Convert errors during critical GuC flows (init, load, reset, suspend)
> to use the xe_log_err() helper.
> While at it, simplify the error log for the GuC load failure to use the
> cached frequency values instead of fetching them again.
> 
> v2: split guc_load_done changes to their own patch, use available ret
> value for reset errors (Michal)
> 
> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
> Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> Cc: Alan Previn Teres Alexis <alan.previn.teres.alexis@intel.com>
> Cc: Julia Filipchuk <julia.filipchuk@intel.com>
> Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
> ---
>  drivers/gpu/drm/xe/xe_guc.c | 19 ++++++++++---------
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/xe/xe_guc.c b/drivers/gpu/drm/xe/xe_guc.c
> index 5285d4cecbc8..d0ddaaf35274 100644
> --- a/drivers/gpu/drm/xe/xe_guc.c
> +++ b/drivers/gpu/drm/xe/xe_guc.c
> @@ -777,7 +777,7 @@ int xe_guc_init_noalloc(struct xe_guc *guc)
>  	return 0;
>  
>  out:
> -	xe_gt_err(gt, "GuC init failed with %pe\n", ERR_PTR(ret));
> +	xe_log_err(gt, GUC, ret, "GuC init failed\n");

note that there will be already "GUC: " prefix in the message,
so maybe just:

	"Initialization error\n"

>  	return ret;
>  }
>  
> @@ -845,7 +845,7 @@ int xe_guc_init(struct xe_guc *guc)
>  	return 0;
>  
>  out:
> -	xe_gt_err(gt, "GuC init failed with %pe\n", ERR_PTR(ret));
> +	xe_log_err(gt, GUC, ret, "GuC init failed\n");

ditto

>  	return ret;
>  }
>  
> @@ -998,15 +998,16 @@ int xe_guc_reset(struct xe_guc *guc)
>  
>  	ret = xe_mmio_wait32(mmio, GDRST, GRDOM_GUC, 0, 5000, &gdrst, false);
>  	if (ret) {
> -		xe_gt_err(gt, "GuC reset timed out, GDRST=%#x\n", gdrst);
> +		xe_log_err(gt, GUC, ret, "GuC reset timed out, GDRST=%#x\n", gdrst);

note that there will be already "GUC: " prefix in the message,
so maybe just:

	"Reset timeout, GDRST=%#x\n"

>  		goto err_out;
>  	}
>  
>  	guc_status = xe_mmio_read32(mmio, GUC_STATUS);
>  	if (!(guc_status & GS_MIA_IN_RESET)) {
> -		xe_gt_err(gt, "GuC status: %#x, MIA core expected to be in reset\n",
> -			  guc_status);
>  		ret = -EIO;
> +		xe_log_err(gt, GUC, ret,
> +			   "GuC status: %#x, MIA core expected to be in reset\n",
> +			   guc_status);

note that there will be already "GUC: " prefix in the message,
so maybe just:

	"MIA core not in reset, GUC_STATUS=%#x\n"

>  		goto err_out;
>  	}
>  
> @@ -1224,9 +1225,9 @@ static int guc_wait_ucode(struct xe_guc *guc)
>  	cur_freq = xe_guc_pc_get_cur_freq_fw(guc_pc);
>  
>  	if (ret || load_result) {
> -		xe_gt_err(gt, "load failed: status = 0x%08X, time = %lldms, freq = %dMHz (req %dMHz)\n",
> -			  status, delta_ms, xe_guc_pc_get_act_freq(guc_pc),
> -			  xe_guc_pc_get_cur_freq_fw(guc_pc));
> +		xe_log_err(gt, GUC, ret ?: load_result,
> +			   "load failed: status = 0x%08X, time = %lldms, freq = %dMHz (req %dMHz)\n",

as "status" is a register dump, maybe use the same naming as before:

	"Load failed, GUC_STATUS=%#x

> +			   status, delta_ms, act_freq, cur_freq);
>  		print_load_status_err(gt, status);

do we want to use xe_log_info() here ^^^ to get a better view?
then maybe above xe_log() could be split and keep only GUC_STATUS
and move rest (freq) to other logs?

>  
>  		return ret ?: load_result;
> @@ -1463,7 +1464,7 @@ int xe_guc_suspend(struct xe_guc *guc)
>  
>  	ret = xe_guc_softreset(guc);
>  	if (ret) {
> -		xe_gt_err(gt, "GuC suspend failed: %pe\n", ERR_PTR(ret));
> +		xe_log_err(gt, GUC, ret, "GuC suspend failed\n");

note that there will be already "GUC: " prefix in the message,
so maybe just:

	"Suspend aborted\n"

>  		return ret;
>  	}
>  


  reply	other threads:[~2026-09-02 14:34 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 21:12 [PATCH v2 0/5] Use SIG_ID logs for GuC component Umesh Nerlige Ramappa
2026-09-01 21:12 ` [PATCH v2 1/5] drm/xe/guc: Use different error codes for GuC load errors Umesh Nerlige Ramappa
2026-09-02 12:56   ` Michal Wajdeczko
2026-09-01 21:12 ` [PATCH v2 2/5] drm/xe/guc: Use different error codes for CT errors Umesh Nerlige Ramappa
2026-09-02 14:22   ` Michal Wajdeczko
2026-09-02 22:35     ` Umesh Nerlige Ramappa
2026-09-01 21:12 ` [PATCH v2 3/5] drm/xe/uc: Report DMA failure using SIGID Umesh Nerlige Ramappa
2026-09-01 21:12 ` [PATCH v2 4/5] drm/xe/guc: Report major GuC failures " Umesh Nerlige Ramappa
2026-09-02 14:33   ` Michal Wajdeczko [this message]
2026-09-02 19:02     ` Umesh Nerlige Ramappa
2026-09-01 21:12 ` [PATCH v2 5/5] drm/xe/guc: Report errors that cause a CT shutdown " Umesh Nerlige Ramappa
2026-09-02 14:45   ` Michal Wajdeczko
2026-09-03 22:21     ` Umesh Nerlige Ramappa
2026-09-01 21:18 ` ✗ CI.checkpatch: warning for Use SIG_ID logs for GuC component Patchwork
2026-09-01 21:20 ` ✓ CI.KUnit: success " Patchwork
2026-09-02  6:57 ` ✓ Xe.CI.BAT: " Patchwork
2026-09-02 12:05 ` ✓ Xe.CI.FULL: " 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=00e3acce-3f21-4aad-a5d8-749e26bf7b2d@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=alan.previn.teres.alexis@intel.com \
    --cc=aravind.iddamsetty@intel.com \
    --cc=daniele.ceraolospurio@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=julia.filipchuk@intel.com \
    --cc=mallesh.koujalagi@intel.com \
    --cc=umesh.nerlige.ramappa@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.