From: "Nilawar, Badal" <badal.nilawar@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
<intel-xe@lists.freedesktop.org>
Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com>,
Rodrigo Vivi <rodrigo.vivi@intel.com>,
Riana Tauro <riana.tauro@intel.com>,
Stuart Summers <stuart.summers@intel.com>,
Yoni Levitt <yoni.levitt@intel.com>,
"Aravind Iddamsetty" <aravind.iddamsetty@intel.com>,
Raag Jadav <raag.jadav@intel.com>
Subject: Re: [PATCH v4 02/32] drm/xe/log: Add structured SIGID error logging infrastructure
Date: Thu, 13 Aug 2026 19:12:41 +0530 [thread overview]
Message-ID: <f617645d-69c6-4fa0-8176-1837b982ab7a@intel.com> (raw)
In-Reply-To: <20260812191450.11690-3-michal.wajdeczko@intel.com>
Hi Michal,
Couple of comments, on rate-limiting and XE_SIGID_WEDGED, from v3
https://patchwork.freedesktop.org/patch/743308/?series=171022&rev=3#comment_1373861
are not answered/addressed.
On 13-08-2026 00:44, Michal Wajdeczko wrote:
> From: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>
> Today the driver reports faults with ad-hoc drm_err()/xe_gt_err()
> strings that have no stable shape. That is readable for a human, but it
> gives fleet tooling nothing durable to match on: the wording changes
> between releases, lines can be rate-limited or dropped under an error
> storm, and there is no consistent way to ask "which recognised fault
> just happened?".
>
> Introduce a signature identifier (SIGID): a small, stable integer that
> names one recognised Xe fault site and serves as the primary handle for
> triage. A SIGID maps, through published end-user documentation, to a
> description and a recommended action; the driver only has to emit the
> right SIGID next to the usual human-readable text.
>
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> Assisted-by: Copilot:Opus-4.8
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> Co-developed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: Riana Tauro <riana.tauro@intel.com>
> Cc: Stuart Summers <stuart.summers@intel.com>
> ---
> Cc: Yoni Levitt <yoni.levitt@intel.com>
> Cc: Aravind Iddamsetty <aravind.iddamsetty@intel.com>
> Cc: Raag Jadav <raag.jadav@intel.com>
> ---
> v2: CORRECTED is still an error (Michal)
> prepare to decorate dmesg with comp/loc (Michal)
> v3: update SIGID DOC section (Riana/Aravind)
> warn about unknown severity (Mallesh)
> ---
> Documentation/gpu/xe/index.rst | 1 +
> Documentation/gpu/xe/xe_sigid.rst | 14 +++
> drivers/gpu/drm/xe/Makefile | 1 +
> drivers/gpu/drm/xe/abi/xe_sigid_abi.h | 159 ++++++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_log.c | 138 ++++++++++++++++++++++
> drivers/gpu/drm/xe/xe_log.h | 20 ++++
> 6 files changed, 333 insertions(+)
> create mode 100644 Documentation/gpu/xe/xe_sigid.rst
> create mode 100644 drivers/gpu/drm/xe/abi/xe_sigid_abi.h
> create mode 100644 drivers/gpu/drm/xe/xe_log.c
> create mode 100644 drivers/gpu/drm/xe/xe_log.h
>
> diff --git a/Documentation/gpu/xe/index.rst b/Documentation/gpu/xe/index.rst
> index 665c0e93601c..0247a255f7e6 100644
> --- a/Documentation/gpu/xe/index.rst
> +++ b/Documentation/gpu/xe/index.rst
> @@ -35,3 +35,4 @@ The display, or :ref:`drm-kms`, support for drm/xe is provided by
> xe-drm-usage-stats.rst
> xe_configfs
> xe_gt_stats
> + xe_sigid
> diff --git a/Documentation/gpu/xe/xe_sigid.rst b/Documentation/gpu/xe/xe_sigid.rst
> new file mode 100644
> index 000000000000..45d84a62f185
> --- /dev/null
> +++ b/Documentation/gpu/xe/xe_sigid.rst
> @@ -0,0 +1,14 @@
> +.. SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +========
> +Xe SIGID
> +========
> +
> +.. kernel-doc:: drivers/gpu/drm/xe/abi/xe_sigid_abi.h
> + :doc: Xe Error Signatures (SIGID)
> +
> +Signature Identifiers
> +=====================
> +
> +.. kernel-doc:: drivers/gpu/drm/xe/abi/xe_sigid_abi.h
> + :internal:
> diff --git a/drivers/gpu/drm/xe/Makefile b/drivers/gpu/drm/xe/Makefile
> index 44ed055439d4..92134709d998 100644
> --- a/drivers/gpu/drm/xe/Makefile
> +++ b/drivers/gpu/drm/xe/Makefile
> @@ -87,6 +87,7 @@ xe-y += xe_bb.o \
> xe_hw_fence.o \
> xe_irq.o \
> xe_late_bind_fw.o \
> + xe_log.o \
> xe_lrc.o \
> xe_mem_pool.o \
> xe_migrate.o \
> diff --git a/drivers/gpu/drm/xe/abi/xe_sigid_abi.h b/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
> new file mode 100644
> index 000000000000..93967183ae51
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
> @@ -0,0 +1,159 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#ifndef _ABI_XE_SIGID_ABI_H_
> +#define _ABI_XE_SIGID_ABI_H_
> +
> +/**
> + * DOC: Xe Error Signatures (SIGID)
> + *
> + * What SIGID stands for
> + * ---------------------
> + *
> + * SIGID is short for *Signature Identifier*. It is a small, stable integer
> + * that names one of *recognised fault site* -- nothing more. It is the
> + * primary handle used for triage and maps directly to specific report site.
> + *
> + * Numbering
> + * ---------
> + *
> + * SIGIDs are a single flat list numbered sequentially within the assigned range,
> + * in the order the fault sites were introduced. Values are stable: once assigned
> + * they are only ever appended, never renumbered or reused. A retired fault site
> + * SIGID value is deprecated in place, never re-purposed.
> + *
> + * Why this exists
> + * ---------------
> + *
> + * Today the driver reports faults with ad-hoc ``xe_err()`` / ``xe_gt_err()``
> + * strings that have no stable shape. That is fine for a human reading dmesg,
> + * but it gives fleet tooling nothing durable to match on: the wording changes
> + * between releases, lines can be rate-limited or dropped under an error storm,
> + * and there is no consistent way to ask "which recognised fault just happened?"
> + *
> + * A SIGID answers exactly that one question, identically across driver and
> + * firmware versions, and (eventually) across other Intel devices in a node.
> + *
> + * What a SIGID is not
> + * -------------------
> + *
> + * SIGID deliberately does not encode the detailed reason or the outcome. Those
> + * are carried alongside it::
> + *
> + * SIGID -> which recognised fault site is being reported
> + * severity -> how serious this instance is
> + * errno -> the failing operation's error, if available, shown with %pe
> + * message -> free-form human-readable context
> + *
> + * Severity is independent of the SIGID. The same SIGID can be reported at
> + * different severities depending on the instance and the recovery taken.
> + *
> + * When to use SIGID logging
> + * -------------------------
> + *
> + * The xe_log_*() helpers are for these recognised fault sites only --
> + * important, operator-relevant faults and events. The driver's only job is to
> + * emit the right SIGID next to the usual human-readable text.
> +
> + * They are not a replacement for ``xe_info()`` / ``xe_dbg()`` / tracing, nor
> + * for one-off diagnostics; using them for ordinary logging would dilute the
> + * fault stream. Not every ``xe_err()`` needs to become a SIGID report -- only
> + * those that correspond to a published fault sites.
> + *
> + * SIGID log output (dmesg vs. the machine record)
> + * -----------------------------------------------
> + *
> + * The dmesg line stays close to a normal xe error message so it remains
> + * readable for admins; the only stable, machine-matchable token on it is
> + * ``SIGID=<n>`` (``dmesg | grep SIGID=``).
> + *
> + * The full dmesg line is not an ABI: the surrounding text may change freely,
> + * and lines may be dropped. The durable record for tooling is the CPER record
> + * carrying the same SIGID (generation is a planned follow-up).
> + *
> + * How to pick a SIGID (the uniqueness rule)
> + * -----------------------------------------
> + *
> + * Pick per *report site*, not per incident. Each site emits the single most
> + * specific recognised SIGID *for that site* -- so the question is never
> + * "classify this whole failure", it is "what does this site detect?", which has
> + * one answer. A single underlying failure therefore legitimately produces a
> + * *chain* of reports from different layers, each with its own SIGID -- e.g. a
> + * GuC communication failure is reported as %XE_SIGID_RUNTIME_FW by the firmware
> + * path, the failed recovery as %XE_SIGID_GT_TDR by the reset path, and an
> + * aborted bind as %XE_SIGID_PROBE by the probe path. That chain lets triage
> + * follow a fault from origin to final effect; it is not a duplicate.
> + *
> + * If a site does not match any defined SIGID, keep using the ordinary
> + * ``xe_err()`` / ``xe_gt_err()`` logging rather than forcing a SIGID: a wrong
> + * or over-broad classification is harder to retire than a missing one. When a
> + * new report site is genuinely worth triaging, add it to the list below.
> + *
> + * Usage of the existing SIGID reports must reevaluated according to this section
> + * after making significant changes to the site that emits this SIGID.
> + *
> + * Scope: software vs hardware emitted signatures
> + * ----------------------------------------------
> + *
> + * Some SIGID represents fault sites that the *driver itself* detects and
> + * reports from the software POV: probe abort, wedged, survivability, driver-
> + * detected firmware failures, engine TDR, memory faults and IO/bus faults.
> + * These are the only values the driver assigns on its own.
> + *
> + * Signatures that *originate* in firmware or hardware are a different thing:
> + * they are produced and identified by the firmware or the hardware itself
> + * (e.g. via their own records or error counters), and the driver merely logs
> + * them as they are given to us. They are deliberately enumerated separately.
> + *
> + * The two driver-detected firmware report sites below (%XE_SIGID_RUNTIME_FW,
> + * %XE_SIGID_DEVICE_FW) are software signatures: they mark that *the driver*
> + * observed a firmware problem, not a signature reported by the firmware.
> + */
> +
> +/*
> + * Top level Intel Error Signature Identifiers.
> + */
> +#define INTEL_SIGID_INVALID 0
> +#define INTEL_SIGID_BATCH 100
> +#define INTEL_SIGID_RANGE_START(n) ((n) * INTEL_SIGID_BATCH)
> +#define INTEL_SIGID_RANGE_END(n) (INTEL_SIGID_RANGE_START((n) + 1) - 1)
> +
> +/* SIGIDs 1xx are reserved for Xe GPU software and 2xx for Xe GPU hardware */
> +#define INTEL_SIGID_GPU_XE_SOFTWARE_START INTEL_SIGID_RANGE_START(1)
> +#define INTEL_SIGID_GPU_XE_SOFTWARE_END INTEL_SIGID_RANGE_END(1)
> +#define INTEL_SIGID_GPU_XE_HARDWARE_START INTEL_SIGID_RANGE_START(2)
> +#define INTEL_SIGID_GPU_XE_HARDWARE_END INTEL_SIGID_RANGE_END(2)
> +
> +/**
> + * enum xe_sigid - Stable Xe Error Signature Identifiers (SIGID).
> + * @XE_SIGID_SW: Software component failure.
> + * @XE_SIGID_PROBE: Device probe/bind was aborted.
> + * @XE_SIGID_WEDGED: Device was declared wedged and is no longer usable.
> + * @XE_SIGID_SURVIVABILITY: Device entered survivability mode.
> + * @XE_SIGID_RUNTIME_FW: Driver-detected runtime firmware failure, GuC/HuC/GSC.
> + * @XE_SIGID_DEVICE_FW: Driver-detected device firmware failure, PCODE/sysctrl.
> + * @XE_SIGID_GT_TDR: Engine hang / timeout detection and recovery (reset).
> + * @XE_SIGID_MEM_FAULT: VM bind, page fault or GTT fault.
> + * @XE_SIGID_IO_BUS: Runtime PCIe / IOMMU / MMIO access fault.
> + *
> + * Each SIGID represents the report sites the driver detects and reports.
> + * Values are numbered sequentially, are only ever appended, and are never
> + * renumbered or reused.
> + *
> + * Firmware- and hardware-originated signatures are not listed yet here.
> + */
> +enum xe_sigid {
> + XE_SIGID_SW = INTEL_SIGID_GPU_XE_SOFTWARE_START,
> + XE_SIGID_PROBE = INTEL_SIGID_GPU_XE_SOFTWARE_START + 1,
> + XE_SIGID_WEDGED = INTEL_SIGID_GPU_XE_SOFTWARE_START + 2,
> + XE_SIGID_SURVIVABILITY = INTEL_SIGID_GPU_XE_SOFTWARE_START + 3,
> + XE_SIGID_RUNTIME_FW = INTEL_SIGID_GPU_XE_SOFTWARE_START + 4,
> + XE_SIGID_DEVICE_FW = INTEL_SIGID_GPU_XE_SOFTWARE_START + 5,
> + XE_SIGID_GT_TDR = INTEL_SIGID_GPU_XE_SOFTWARE_START + 6,
> + XE_SIGID_MEM_FAULT = INTEL_SIGID_GPU_XE_SOFTWARE_START + 7,
> + XE_SIGID_IO_BUS = INTEL_SIGID_GPU_XE_SOFTWARE_START + 8,
> +};
> +
> +#endif
> diff --git a/drivers/gpu/drm/xe/xe_log.c b/drivers/gpu/drm/xe/xe_log.c
> new file mode 100644
> index 000000000000..ae4f6e33f5b8
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_log.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#include "xe_log.h"
> +#include "xe_printk.h"
> +
> +static void log_emit_cper(struct pci_dev *pdev, int cper_sev, enum xe_sigid sigid,
> + u32 component, u32 location, const void *data, size_t len,
> + struct va_format *vaf)
> +{
> + /* TODO */
> +}
> +
> +static bool is_hw_sigid(enum xe_sigid sigid)
> +{
> + return (int)sigid >= INTEL_SIGID_GPU_XE_HARDWARE_START;
> +}
> +
> +static bool is_sev_error(int cper_sev)
> +{
> + return cper_sev != CPER_SEV_INFORMATIONAL;
> +}
> +
> +static const char *log_hwe_prefix(int cper_sev, enum xe_sigid sigid)
> +{
> + return is_sev_error(cper_sev) && is_hw_sigid(sigid) ? HW_ERR : "";
> +}
> +
> +static const char *log_sev_prefix(int cper_sev)
> +{
> + switch (cper_sev) {
> + case CPER_SEV_FATAL:
> + return "FATAL ";
> + case CPER_SEV_RECOVERABLE:
> + return "";
> + case CPER_SEV_CORRECTED:
> + return "CORRECTED ";
> + case CPER_SEV_INFORMATIONAL:
> + return "";
> + default:
> + WARN(IS_ENABLED(CONFIG_DRM_XE_DEBUG), "LOG: unknown severity %d\n", cper_sev);
> + return "";
> + }
> +}
> +
> +#define __LOG_DRM_PRINTK_FMT(fmt, args...) "[drm] " fmt, ##args
> +#define __LOG_DRM_PRINTK_ERR_FMT(fmt, args...) __LOG_DRM_PRINTK_FMT("*ERROR* " fmt, args)
> +
> +static void log_dmesg_vprintk(struct pci_dev *pdev, int cper_sev, struct va_format *vaf)
> +{
> + if (cper_sev == CPER_SEV_INFORMATIONAL)
> + pci_info(pdev, __LOG_DRM_PRINTK_FMT("%pV", vaf));
> + else
> + pci_err(pdev, __LOG_DRM_PRINTK_ERR_FMT("%pV", vaf));
> +}
> +
> +static void log_dmesg_printf(struct pci_dev *pdev, int cper_sev, const char *fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, fmt);
> + vaf.fmt = fmt;
> + vaf.va = &args;
> +
> + log_dmesg_vprintk(pdev, cper_sev, &vaf);
> +
> + va_end(args);
> +}
> +
> +static void log_emit_dmesg(struct pci_dev *pdev, int cper_sev, enum xe_sigid sigid,
> + u32 component, u32 location, const void *data, size_t len,
> + struct va_format *vaf)
> +{
> + const char *hwe_prefix = log_hwe_prefix(cper_sev, sigid);
> + const char *sev_prefix = log_sev_prefix(cper_sev);
> +
> + /* TODO: add component/location details */
> +
> + if (IS_ERR(data))
> + log_dmesg_printf(pdev, cper_sev, "SIGID=%u %s(%pe) %s%pV",
> + sigid, sev_prefix, data, hwe_prefix, vaf);
> + else if (data && len)
> + log_dmesg_printf(pdev, cper_sev, "SIGID=%u %s(%*phN) %s%pV",
> + sigid, sev_prefix, (int)len, data, hwe_prefix, vaf);
> + else
> + log_dmesg_printf(pdev, cper_sev, "SIGID=%u %s%s%pV",
> + sigid, sev_prefix, hwe_prefix, vaf);
> +}
> +
> +/**
> + * xe_log_emit() - Emit a structured SIGID log entry
> + * @pdev: the &pci_dev device
> + * @cper_sev: CPER severity (CPER_SEV_FATAL, CPER_SEV_RECOVERABLE, ...)
> + * @sigid: signature identifier, see &enum xe_sigid
> + * @component: component identifer
> + * @location: location details of the @component
> + * @data: pointer to the additional details, or ERR_PTR, or NULL if not applicable
> + * @len: length of the @data in bytes, or 0 if not applicable
> + * @fmt: printf-style format string
> + * @...: format arguments
> + *
> + * Emits a dmesg line that includes a single stable, machine-matchable token
> + * ``SIGID=<n>`` followed by the optional severity token (like ``FATAL``) and,
> + * when @data pointer is set, either the error printed with %pe or a packed hex
> + * dump of the @data binary blob. The dmesg line will also include printf-style
> + * text message.
> + *
> + * Note that the full dmesg line, with the free text message, is only a debugging
> + * aid, not an interface! Only the ``SIGID=<n>`` token is stable there.
> + * The durable machine record is the CPER carrying the same SIGID.
> + *
> + * Note: generation of the CPER record is a planned follow-up.
> + *
> + * Examples::
> + *
> + * <3> xe 0000:03:00.0: [drm] *ERROR* SIGID=104 FATAL (-EPROTO) Invalid GuC reply
> + * <3> xe 0000:03:00.0: [drm] *ERROR* SIGID=106 (-ETIMEDOUT) Engine 'rcs0' hung
> + * <6> xe 0000:03:00.0: [drm] SIGID=103 In survivability mode
> + */
> +void xe_log_emit(struct pci_dev *pdev, int cper_sev, enum xe_sigid sigid,
> + u32 component, u32 location, const void *data, size_t len,
> + const char *fmt, ...)
> +{
> + struct va_format vaf;
> + va_list args;
> +
> + va_start(args, fmt);
> + vaf.fmt = fmt;
> + vaf.va = &args;
> +
> + log_emit_dmesg(pdev, cper_sev, sigid, component, location, data, len, &vaf);
> + log_emit_cper(pdev, cper_sev, sigid, component, location, data, len, &vaf);
> +
From kunit example I got this output for hardware errors.
drm-kunit-mock-device demo_dmesg.drm-kunit-mock-device: [drm] *ERROR*
SIGID=204 (0102030405060708090a0b0c) [Hardware Error]: testing HARDWARE
signature
drm-kunit-mock-device demo_dmesg.drm-kunit-mock-device: [drm] *ERROR*
SIGID=202 CORRECTED (0102030405060708090a0b0c) [Hardware Error]: Tile1:
testing HARDWARE signature
SIGIDs 202 and 204 correspond to the XE_RAS_COMP_DEVICE_MEMORY and
XE_RAS_COMP_FABRIC components returned by firmware via xe_ras_error_class.
If we want the component name to be included in the error message, what
should be passed to the logging helper? The current KUnit test uses
XE_LOG_COMPONENT_NONE, so no component information is being emitted.
Thanks,
Badal
> + va_end(args);
> +}
> diff --git a/drivers/gpu/drm/xe/xe_log.h b/drivers/gpu/drm/xe/xe_log.h
> new file mode 100644
> index 000000000000..d475e816ee0b
> --- /dev/null
> +++ b/drivers/gpu/drm/xe/xe_log.h
> @@ -0,0 +1,20 @@
> +/* SPDX-License-Identifier: MIT */
> +/*
> + * Copyright © 2026 Intel Corporation
> + */
> +
> +#ifndef _XE_LOG_H_
> +#define _XE_LOG_H_
> +
> +#include <linux/cper.h>
> +
> +#include "abi/xe_sigid_abi.h"
> +
> +struct pci_dev;
> +
> +__printf(8, 9)
> +void xe_log_emit(struct pci_dev *pdev, int cper_sev, enum xe_sigid sigid,
> + u32 component, u32 location, const void *data, size_t len,
> + const char *fmt, ...);
> +
> +#endif
next prev parent reply other threads:[~2026-08-13 13:42 UTC|newest]
Thread overview: 109+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 19:14 [PATCH v4 00/32] drm/xe: Add structured SIGID error logging infrastructure Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 01/32] drm/xe: Introduce xe_any helpers Michal Wajdeczko
2026-08-12 19:29 ` sashiko-bot
2026-08-13 16:51 ` Rodrigo Vivi
2026-08-13 23:37 ` Mallesh, Koujalagi
2026-08-12 19:14 ` [PATCH v4 02/32] drm/xe/log: Add structured SIGID error logging infrastructure Michal Wajdeczko
2026-08-13 13:33 ` Mallesh, Koujalagi
2026-08-13 13:57 ` Michal Wajdeczko
2026-08-13 13:42 ` Nilawar, Badal [this message]
2026-08-13 19:00 ` Rodrigo Vivi
2026-08-14 13:05 ` Nilawar, Badal
2026-08-14 13:54 ` Michal Wajdeczko
2026-08-13 20:38 ` Michal Wajdeczko
2026-08-14 13:19 ` Nilawar, Badal
2026-08-13 18:51 ` Rodrigo Vivi
2026-08-14 13:32 ` Nilawar, Badal
2026-08-14 14:00 ` Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 03/32] drm/xe/log: Introduce structured component/location identifiers Michal Wajdeczko
2026-08-13 17:20 ` Rodrigo Vivi
2026-08-12 19:14 ` [PATCH v4 04/32] drm/xe/log: Add component/location decorations to dmesg Michal Wajdeczko
2026-08-14 0:00 ` Mallesh, Koujalagi
2026-08-12 19:14 ` [PATCH v4 05/32] drm/xe/log: Add SIGID log helpers for severity Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 06/32] drm/xe/log: Add SIGID log helpers for location Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 07/32] drm/xe/log: Add SIGID log helpers for location & severity Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 08/32] drm/xe/log: Add SIGID log helpers for components Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 09/32] drm/xe/log: Add SIGID log helpers for component & severity Michal Wajdeczko
2026-08-13 4:38 ` Mallesh, Koujalagi
2026-08-12 19:14 ` [PATCH v4 10/32] drm/xe/log: Add SIGID log helpers for errno-only Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 11/32] drm/xe/log: Index all SIGID printk messages Michal Wajdeczko
2026-08-12 19:35 ` sashiko-bot
2026-08-13 12:31 ` Mallesh, Koujalagi
2026-08-13 12:54 ` Michal Wajdeczko
2026-08-13 13:29 ` Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 12/32] drm/xe/log: Add hardware error signatures Michal Wajdeczko
2026-08-13 5:03 ` Mallesh, Koujalagi
2026-08-12 19:14 ` [PATCH v4 13/32] drm/xe/log: Extend components list with hardware items Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 14/32] drm/xe/ras: Check RAS and LOG component definitions Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 15/32] drm/xe/kunit: Setup driver data in the test device Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 16/32] drm/xe/tests: Add Kunit tests for xe_log Michal Wajdeczko
2026-08-14 13:36 ` Nilawar, Badal
2026-08-14 14:11 ` Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 17/32] drm/xe/tests: Add kunit tests for xe_any Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 18/32] drm/xe: Report 'probe blocked' error using SIGID Michal Wajdeczko
2026-08-13 6:26 ` Mallesh, Koujalagi
2026-08-12 19:14 ` [PATCH v4 19/32] drm/xe: Report all probe errors " Michal Wajdeczko
2026-08-13 6:50 ` Mallesh, Koujalagi
2026-08-13 9:12 ` Michal Wajdeczko
2026-08-13 9:58 ` Mallesh, Koujalagi
2026-08-13 10:09 ` Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 20/32] drm/xe/survivability: Report 'boot status' " Michal Wajdeczko
2026-08-13 8:38 ` Mallesh, Koujalagi
2026-08-13 9:28 ` Michal Wajdeczko
2026-08-13 10:07 ` Mallesh, Koujalagi
2026-08-13 10:18 ` Michal Wajdeczko
2026-08-14 10:46 ` Tauro, Riana
2026-08-14 13:38 ` Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 21/32] drm/xe/survivability: Report 'sysfs failure' error " Michal Wajdeczko
2026-08-13 8:54 ` Mallesh, Koujalagi
2026-08-14 10:34 ` Tauro, Riana
2026-08-14 13:32 ` Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 22/32] drm/xe/survivability: Report 'Boot Mode enabled' status " Michal Wajdeczko
2026-08-13 10:52 ` Mallesh, Koujalagi
2026-08-13 11:01 ` Michal Wajdeczko
2026-08-14 6:31 ` Tauro, Riana
2026-08-14 10:06 ` Michal Wajdeczko
2026-08-14 10:20 ` Tauro, Riana
2026-08-14 10:40 ` Michal Wajdeczko
2026-08-14 10:51 ` Tauro, Riana
2026-08-14 13:17 ` Michal Wajdeczko
2026-08-14 12:40 ` Mallesh, Koujalagi
2026-08-12 19:14 ` [PATCH v4 23/32] drm/xe/survivability: Report 'Runtime " Michal Wajdeczko
2026-08-13 11:40 ` Mallesh, Koujalagi
2026-08-13 12:46 ` Michal Wajdeczko
2026-08-13 13:16 ` Mallesh, Koujalagi
2026-08-14 7:06 ` Tauro, Riana
2026-08-14 10:18 ` Michal Wajdeczko
2026-08-14 10:27 ` Tauro, Riana
2026-08-14 13:26 ` Michal Wajdeczko
2026-08-14 13:00 ` Mallesh, Koujalagi
2026-08-14 13:46 ` Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 24/32] drm/xe: Report 'device wedged' errors " Michal Wajdeczko
2026-08-12 22:28 ` Rodrigo Vivi
2026-08-13 11:56 ` Mallesh, Koujalagi
2026-08-12 19:14 ` [PATCH v4 25/32] drm/xe/pcode: Report 'Mailbox failed' error " Michal Wajdeczko
2026-08-13 12:10 ` Bhadane, Dnyaneshwar
2026-08-13 12:35 ` Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 26/32] drm/xe/pcode: Report 'timeout, retrying' " Michal Wajdeczko
2026-08-12 19:51 ` sashiko-bot
2026-08-13 16:46 ` Umesh Nerlige Ramappa
2026-08-13 18:42 ` Rodrigo Vivi
2026-08-12 19:14 ` [PATCH v4 27/32] drm/xe/pcode: Report 'initialization timedout' " Michal Wajdeczko
2026-08-12 19:49 ` sashiko-bot
2026-08-13 18:40 ` Rodrigo Vivi
2026-08-12 19:14 ` [PATCH v4 28/32] drm/xe/guc: Report 'GuC mmio' errors " Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 29/32] drm/xe/gt: Report 'reset failed' " Michal Wajdeczko
2026-08-12 19:14 ` [PATCH v4 30/32] drm/xe/gt: Report 'Fault response' pagefault error " Michal Wajdeczko
2026-08-13 18:37 ` Rodrigo Vivi
2026-08-13 19:46 ` Michal Wajdeczko
2026-08-13 22:12 ` Daniele Ceraolo Spurio
2026-08-14 10:30 ` Michal Wajdeczko
2026-08-14 12:49 ` Rodrigo Vivi
2026-08-12 19:14 ` [PATCH v4 31/32] drm/xe/gt: Report 'Queue full' " Michal Wajdeczko
2026-08-13 17:25 ` Rodrigo Vivi
2026-08-12 19:14 ` [PATCH v4 32/32] drm/xe/pci: Report 'cannot re-enable' " Michal Wajdeczko
2026-08-13 17:21 ` Rodrigo Vivi
2026-08-12 19:22 ` ✗ CI.checkpatch: warning for drm/xe: Add structured SIGID error logging infrastructure (rev4) Patchwork
2026-08-12 19:24 ` ✓ CI.KUnit: success " Patchwork
2026-08-12 20:34 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-08-13 2:47 ` ✗ 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=f617645d-69c6-4fa0-8176-1837b982ab7a@intel.com \
--to=badal.nilawar@intel.com \
--cc=aravind.iddamsetty@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=raag.jadav@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=stuart.summers@intel.com \
--cc=yoni.levitt@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