Re: [PATCH v3 10/23] drm/xe/log: Add hardware error signatures

On 04-08-2026 21:26, Michal Wajdeczko wrote:
>
> On 7/31/2026 1:41 PM, Mallesh, Koujalagi wrote:
>> On 30-07-2026 08:51 pm, Michal Wajdeczko wrote:
>>> Extend our error signatures definitions xe_sigid to cover also
>>> hardware-originated errors and make them distinguishable from
>>> initially defined software-initiated errors.
>>>
>>> Signed-off-by: Michal Wajdeczko <[email protected]>
>>> Cc: Rodrigo Vivi <[email protected]>
>>> Cc: Yoni Levitt <[email protected]>
>>> ---
>>> v2: update comment (Sashiko)
>>> ---
>>>    drivers/gpu/drm/xe/abi/xe_sigid_abi.h | 16 ++++++++++++++--
>>>    1 file changed, 14 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/abi/xe_sigid_abi.h b/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
>>> index 99717fdf74a6..69cce4b45635 100644
>>> --- a/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
>>> +++ b/drivers/gpu/drm/xe/abi/xe_sigid_abi.h
>>> @@ -159,14 +159,19 @@
>>>     * @XE_SIGID_GT_TDR: Engine hang / timeout detection and recovery (reset). [RETRY]
>>>     * @XE_SIGID_MEM_FAULT: VM bind, page fault or GTT fault. [COLLECT]
>>>     * @XE_SIGID_IO_BUS: Runtime PCIe / IOMMU / MMIO access fault. [RECOVER]
>>> + * @XE_SIGID_HW: Generic hardware failure.
>>> + * @XE_SIGID_PCIE: PCIe interface errors.
>>> + * @XE_SIGID_DEVICE_MEMORY: Device memory errors
>> Add . @ end
>>> + * @XE_SIGID_CORE_COMPUTE: Compute/shader core errors.
>>> + * @XE_SIGID_FABRIC: Fabric errors.
>>> + * @XE_SIGID_SOC_INTERNAL: SoC-internal errors.
>>>     *
>>>     * The situations the driver detects and reports in software. Values are
>>>     * numbered sequentially, are only ever appended, and are never renumbered or
>>>     * reused. The tag in brackets is the default resolution bucket (see the `Xe
>>>     * Error Signatures (SIGID)`_ section).
>>>     *
>>> - * Firmware- and hardware-originated signatures are not listed here; they are
>>> - * logged as reported by those layers.
>>> + * Firmware- and hardware-originated signatures are numbered separately.
>>>     */
>>>    enum xe_sigid {
>>>        XE_SIGID_SW            = INTEL_SIGID_GPU_XE_SOFTWARE_START,
>>> @@ -178,6 +183,13 @@ enum xe_sigid {
>>>        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,
>>> +
>>> +    XE_SIGID_HW            = INTEL_SIGID_GPU_XE_HARDWARE_START,
>>> +    XE_SIGID_PCIE            = INTEL_SIGID_GPU_XE_HARDWARE_START + 1,
>>> +    XE_SIGID_DEVICE_MEMORY        = INTEL_SIGID_GPU_XE_HARDWARE_START + 2,
>>> +    XE_SIGID_CORE_COMPUTE        = INTEL_SIGID_GPU_XE_HARDWARE_START + 3,
>>> +    XE_SIGID_FABRIC            = INTEL_SIGID_GPU_XE_HARDWARE_START + 4,
>>> +    XE_SIGID_SOC_INTERNAL        = INTEL_SIGID_GPU_XE_HARDWARE_START + 5,

Nit: Maybe retain the same order as firmware

>> Since we've resolution bucket for SW sigid so do we need resolution bucket for HW sigid as well? If so how are we going to put HW sigid to resolution bucket?

We shouldn't be having resolution buckets here. This is just the high 
level class.
For ex: Soc internal has multiple recoveries. I think the decision in 
02/23 was drop resolution buckets.

Thanks
Riana

> there was discussion about this already [1]
>
> and I guess we can add [COLLECT] here as an overall recommendation for all HW SIGIDs,
> as likely all such errors will sooner or later be reported as separate SW incidents with its own resolutions
> and official documentation will have more detailed recommendations (out of our scope here)
>
> [1] https://patchwork.freedesktop.org/patch/742246/?series=171022&rev=1#comment_1368419
>
>> Thanks,
>>
>> -/Mallesh
>>
>>>    };
>>>      #endif