Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Wajdeczko <michal.wajdeczko@intel.com>
To: Mallesh Koujalagi <mallesh.koujalagi@intel.com>,
	<intel-xe@lists.freedesktop.org>, <rodrigo.vivi@intel.com>,
	<matthew.brost@intel.com>, <thomas.hellstrom@linux.intel.com>
Cc: <anshuman.gupta@intel.com>, <badal.nilawar@intel.com>,
	<vinay.belgaumkar@intel.com>, <aravind.iddamsetty@intel.com>,
	<riana.tauro@intel.com>, <karthik.poosa@intel.com>,
	<sk.anirban@intel.com>, <raag.jadav@intel.com>
Subject: Re: [RFC PATCH v3 1/3] drm/xe: Add error Signature IDs for RAS logging
Date: Sat, 20 Jun 2026 19:02:04 +0200	[thread overview]
Message-ID: <db58c7ea-8d55-40c6-9fc7-b69878a02505@intel.com> (raw)
In-Reply-To: <20260617104711.79646-6-mallesh.koujalagi@intel.com>



On 6/17/2026 12:47 PM, Mallesh Koujalagi wrote:
> Every GPU fault needs a stable numeric label so monitoring tools can

so the goal is to assign unique number to each GPU error that we report?

can't we teach the monitoring tools to use the message pattern instead?

or maybe it's not about unique signature but rather class of Xe GPU errors?
like HW_ERR defined in [1] for generic hardware errors?

[1] https://elixir.bootlin.com/linux/v7.1/source/include/linux/printk.h#L118

> identify what went wrong without parsing log text. 

hmm, but they will have to parse this text already to find that ID

> Add xe_sig_ids.h
> which defines those labels, called SIG_IDs.

SIG_ID looks like an acronym already - can we know the full real name?

the 'signature' suggests uniqueness, but below definitions are more like a 'class' of errors/faults
> 
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> ---
> v3:
> - Add HW SIG IDS details. (Riana)
> ---
>  drivers/gpu/drm/xe/xe_sig_ids.h | 29 +++++++++++++++++++++++++++++
>  1 file changed, 29 insertions(+)
>  create mode 100644 drivers/gpu/drm/xe/xe_sig_ids.h
> 
> diff --git a/drivers/gpu/drm/xe/xe_sig_ids.h b/drivers/gpu/drm/xe/xe_sig_ids.h
> new file mode 100644
> index 000000000000..7badd0d7ad72
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_sig_ids.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#ifndef _XE_SIG_IDS_H_
> +#define _XE_SIG_IDS_H_
> +
> +/*
> + * Driver SIG_IDs

please add kernel-doc for SIG_IDs itself
maybe then it will be clear what is it

based on the "Every GPU fault needs a stable numeric label"
maybe the more appropriate name would be names like:

	XE_ERROR_
	XE_FAULT_


> + */
> +#define XE_SIG_PROBE			1  /* FATAL: probe failed */
> +#define XE_SIG_WEDGED			2  /* FATAL: device wedged */
> +#define XE_SIG_SURVIVABILITY		3  /* FATAL: survivability mode */
> +#define XE_SIG_FW			4  /* RECOVERABLE: GuC/HuC/UC/GSC/CSC/PCODE */
> +#define XE_SIG_GT_TDR			5  /* RECOVERABLE: engine hang / reset */
> +#define XE_SIG_MEM_FAULT		6  /* RECOVERABLE: VM bind, page fault, GTT */
> +#define XE_SIG_IO_BUS			7  /* RECOVERABLE: runtime PCIe/IOMMU/MMIO */

at this patch, there is no description what FATAL or RECOVERABLE (severity?) really means here
also, if there is a strict relation between SIG and its severity, then maybe those definitions should look like:

#define XE_SIG_PROBE			XE_SIG(1, FATAL)
#define XE_SIG_WEDGED			XE_SIG(2, FATAL)
...

but

> +
> +/*
> + * HW SIG_IDs
> + */

below SIGs do not have associated severity
why the same family of IDs is defined so differently?

> +#define XE_SIG_HW_DEVICE_MEMORY		8  /* Device memory errors (e.g. ECC) */
> +#define XE_SIG_HW_CORE_COMPUTE		9  /* Compute/shader core errors */
> +#define XE_SIG_HW_PCIE			10 /* PCIe interface errors */
> +#define XE_SIG_HW_FABRIC		11 /* On-package fabric errors */
> +#define XE_SIG_HW_SOC_INTERNAL		12 /* SoC-internal errors */

what's the plan for extending SW or HW SIG_IDs in the future?
as now it looks that will not be able to have new SW IDs together with old ones

and I guess the goal is to not change the IDs assignments

> +
> +#endif /* _XE_SIG_IDS_H_ */


  parent reply	other threads:[~2026-06-20 17:02 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-17 10:47 [RFC PATCH v3 0/3] drm/xe: Structured RAS error logging infrastructure Mallesh Koujalagi
2026-06-17 10:47 ` [RFC PATCH v3 1/3] drm/xe: Add error Signature IDs for RAS logging Mallesh Koujalagi
2026-06-19  5:48   ` Tauro, Riana
2026-06-23  7:41     ` Mallesh, Koujalagi
2026-06-20 17:02   ` Michal Wajdeczko [this message]
2026-06-24 11:51     ` Mallesh, Koujalagi
2026-06-17 10:47 ` [RFC PATCH v3 2/3] drm/xe: Add RAS logging helpers Mallesh Koujalagi
2026-06-19  5:43   ` Tauro, Riana
2026-06-23 10:41     ` Mallesh, Koujalagi
2026-06-20 19:29   ` Michal Wajdeczko
2026-06-24 16:03     ` Mallesh, Koujalagi
2026-07-03 11:23       ` Tauro, Riana
2026-06-17 10:47 ` [RFC PATCH v3 3/3] drm/xe: use XE_RAS_WEDGED macro in xe_device_declare_wedged Mallesh Koujalagi
2026-06-17 16:06   ` Bhadane, Dnyaneshwar
2026-06-20 19:39   ` Michal Wajdeczko
2026-06-24 16:16     ` Mallesh, Koujalagi
2026-06-17 11:11 ` ✗ CI.checkpatch: warning for drm/xe: Structured RAS error logging infrastructure (rev3) Patchwork
2026-06-17 11:11 ` ✗ CI.KUnit: failure " 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=db58c7ea-8d55-40c6-9fc7-b69878a02505@intel.com \
    --to=michal.wajdeczko@intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=aravind.iddamsetty@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=karthik.poosa@intel.com \
    --cc=mallesh.koujalagi@intel.com \
    --cc=matthew.brost@intel.com \
    --cc=raag.jadav@intel.com \
    --cc=riana.tauro@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=sk.anirban@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=vinay.belgaumkar@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