Re: [RFC PATCH v4 1/5] drm/xe: Add SIG_IDs for RAS error logging

[Raag Jadav <raag.jadav@intel.com>]

On Tue, Jun 30, 2026 at 05:25:05PM +0530, Mallesh Koujalagi wrote:
> Add xe_sig_ids.h which defines a set of stable numeric labels
> for Xe error categories, called SIG_IDs.
> 
> Each SIG_ID identifies which subsystem reported an error (e.g. probe,
> wedged, GT TDR, firmware). It does not encode the full failure details,
> those come from errno and the free-form message:
> 
>   SIG_ID  -> which area failed
>   errno   -> what failed
>   message -> extra human-readable context
> 
> Also add a DOC: kernel-doc section covering design rationale, driver
> severity labels (FATAL/RECOVERABLE), usage guidelines, and the
> distinction between driver and hardware error paths.

...

> +/**
> + * DOC: SIG_ID Overview
> + *
> + * Signature ID (SIG_ID) is a stable numeric identifier (u16) for a defined
> + * Xe error category - it answers: "which subsystem reported the error?"

Introducing a new concept is a bit of an uphill battle in itself, not
because it lacks an explanation but because the explanation often assumes
that the reader has the same context as the writer and what we end up
with is a terminology soup that doesn't add much to the understanding :)

> + * SIG_ID format
> + * =============
> + *
> + * Xe error events are emitted as a single structured line using stable fields.
> + * Driver events use:
> + *
> + *   [xe-err] SIG_ID = <u16> Severity = <CPER_SEV_*>
> + *            Location = <device|tile/gt> Errno = <neg_errno>
> + *            Message = "<free-form text>"
> + *
> + * Hardware-originated RAS events use the same overall format, but typically
> + * omit Errno and Message and instead report the hardware-derived location /
> + * error-class information.
> + *
> + * Important
> + * =========
> + *
> + * SIG_ID identifies the reporting subsystem/category only. It does not encode
> + * the detailed failure reason. The detailed reason is carried separately by::
> + *
> + *   SIG_ID   -> which subsystem/category failed

So what exactly is "category" or "subsystem" and what fits the criteria of
it? In RAS context we have a unique ID attached to all hardware units (which
we've already defined under xe_ras), so similar to that, what makes a SIG_ID
unique?

Btw, I'm really unsure if 'probe' or 'wedged' are subsystems ;)

> + *   Severity -> how serious the event is
> + *   Errno    -> what failed (driver events)
> + *   Message  -> human-readable context
> + *
> + * Example (driver event)

In Linux world these are not events, so I'd try to find a better terminology
(and in all other places where applicable).

> + * ======================
> + *
> + *   [xe-err] SIG_ID = 6 Severity = CPER_SEV_RECOVERABLE
> + *   Location = tile0/gt0 Errno = -5
> + *   Message = "Engine 'rcs0' hung; TDR triggered, engine reset succeeded"
> + *
> + * In the example
> + * ==============
> + *
> + *   SIG_ID 6   = XE GT/TDR category
> + *   RECOVERABLE = workload impacted, device still operational
> + *   -5         = Linux errno (-EIO)
> + *   Message    = extra context for triage
> + *
> + * Why SIG_ID exists?
> + * ==================
> + *
> + * The goal is to replace inconsistent ad-hoc error strings with a small
> + * set of stable, structured error events that are easier for operators
> + * and tools to understand. Each driver event carries a fixed SIG_ID with
> + * a severity determined by its error category, and structured output that
> + * can be consumed consistently across driver or firmware versions. It
> + * reduces guesswork during triage and allows machine parsing of important
> + * fault events.

Okay so the problem statement is good enough but let's say the tools actually
parse these IDs, what do you expect the outcome of the parsing to be? What
will the results be used for?

I understand the telemetry aspect, but if the expectation is to perform a
"certain recovery procedure" based on the ID, wouldn't it be more intuitive
to just define the IDs based on procedure itself?

> + * Driver severity labels
> + * ======================
> + *
> + * FATAL means the device cannot continue operation (e.g. probe failure,
> + * device wedged). RECOVERABLE means the driver encountered an error but
> + * may continue with degraded functionality.
> + *
> + * When to use the xe_ras_log helpers (see xe_ras_log.h)
> + * =====================================================
> + *
> + * Use them only for defined Xe error events that belong to the published
> + * error categories. These helpers are intended for important fault paths
> + * such as probe failure, wedged device, survivability mode, firmware
> + * failures, GT hang/TDR/reset, memory faults, and runtime IO/bus faults.
> + * The selected macro fixes the SIG_ID and severity for that category.
> + *
> + * Do not use xe_ras_log helpers for all logs
> + * ==========================================
> + *
> + * These helpers are not a replacement for normal drm_info(), drm_dbg(),
> + * tracing, or one-off diagnostics. They are for stable, structured error
> + * reporting only. Using them for ordinary logs would dilute the error
> + * stream and make operator-facing fault reporting noisy and less useful.
> + *
> + * Hardware errors
> + * ===============
> + *
> + * Hardware errors are hardware-reported RAS events and map to the
> + * XE_SIG_HW_* identifiers. They are reported through the hardware error
> + * path (e.g. CPER records), not through the driver xe_ras_log helpers.
> + *
> + * Unlike driver xe_ras_log helpers, hardware events do not have one fixed
> + * severity per SIG_ID. For example, a fabric event (XE_SIG_HW_FABRIC) may
> + * be reported as CPER_SEV_CORRECTED, CPER_SEV_FATAL, CPER_SEV_RECOVERABLE,
> + * or CPER_SEV_INFORMATIONAL, depending on what the hardware reported.
> + */
> +
> +/*
> + * Driver errors: SIG_IDs
> + */
> +#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_RUNTIME_FW		4  /* RECOVERABLE: GuC/HuC/UC/GSC */
> +#define XE_SIG_DEVICE_FW		5  /* RECOVERABLE: PCODE/CSC/System controller */
> +#define XE_SIG_GT_TDR			6  /* RECOVERABLE: engine hang / reset */
> +#define XE_SIG_MEM_FAULT		7  /* RECOVERABLE: VM bind, page fault, GTT */
> +#define XE_SIG_IO_BUS			8  /* RECOVERABLE: runtime PCIe/IOMMU/MMIO */

Many of the above actually overlap, for example boottime survivability or
firmware load failure will result in probe failure, while runtime survivability
or GT reset failure will result in wedging. So which ID is exactly applicable
in those cases and how does it help the usecase here?

> +/*
> + * Hardware errors: SIG_IDs
> + */
> +#define XE_SIG_HW_DEVICE_MEMORY		9  /* Device memory errors */
> +#define XE_SIG_HW_CORE_COMPUTE		10 /* Compute/shader core errors */
> +#define XE_SIG_HW_PCIE			11 /* PCIe interface errors */
> +#define XE_SIG_HW_FABRIC		12 /* Fabric errors */
> +#define XE_SIG_HW_SOC_INTERNAL		13 /* SoC-internal errors */

So is this to be reused in CPER or is that its own thing?

Confused :(

Raag

> +#endif /* _XE_SIG_IDS_H_ */
> -- 
> 2.34.1
>