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

["Mallesh, Koujalagi" <mallesh.koujalagi@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 8500 bytes --]


On 30-06-2026 07:55 pm, Raag Jadav wrote:
> 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 ;)

Good point. "Subsystem/category" is imprecise, especially since values 
like probe and wedged are not

subsystems. SIG_ID is the stable top-level identifier for a Xe error 
report. Each top-level error reporting family

has an unique SIG_ID number. I'll reword the comment to make that explicit.

>> + *   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).
Agreed. I'll change event to error report.
>
>> + * ======================
>> + *
>> + *   [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?

The purpose of parsing SIG_ID is to classify a reported Xe error into a 
stable

top-level family so tools can bucket, aggregate , alert etc. The parsed 
result combined

with severity and detailed fields to decide what action, if any, is 
appropriate.

SIG_ID should identify the kind of error, not the recovery action, 
because recovery actions can change over time.

>> + * 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?

The intent is to use SIG_ID for the specific error report being emitted. 
For example

Bootime survivability failure during probe should use the 
XE_SIG_SURVIVABILITY, XE_SIG_PROBE like

chain of failure which will report all and help to triage.

>> +/*
>> + * 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?

Hardware SIG_IDs are used alonside CPER, not instead of it.

SIG_ID provides a stable top-level Xe error reporting family, while CPER 
remains the source of

detailed hardware component/type/cause information.

Thanks,

-/Mallesh


>
> Confused :(
>
> Raag
>
>> +#endif /* _XE_SIG_IDS_H_ */
>> -- 
>> 2.34.1
>>

[-- Attachment #2: Type: text/html, Size: 10810 bytes --]