From: Aravind Iddamsetty <aravind.iddamsetty@linux.intel.com>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>,
"Nilawar, Badal" <badal.nilawar@intel.com>,
Aravind Iddamsetty <aravind.iddamsetty@intel.com>
Cc: Riana Tauro <riana.tauro@intel.com>,
intel-xe@lists.freedesktop.org, anshuman.gupta@intel.com,
raag.jadav@intel.com, ravi.kishore.koppuravuri@intel.com,
mallesh.koujalagi@intel.com, soham.purkait@intel.com
Subject: Re: [PATCH 1/2] drm/xe/xe_ras: Add Fabric error handling
Date: Thu, 27 Aug 2026 16:25:48 +0530 [thread overview]
Message-ID: <6f8e5f5e-7bd8-4fef-b714-ef077f50812a@linux.intel.com> (raw)
In-Reply-To: <ao9T2POk0wXbGf4L@intel.com>
On 27-08-2026 02:30, Rodrigo Vivi wrote:
> On Tue, Aug 25, 2026 at 08:20:36PM +0530, Nilawar, Badal wrote:
>> On 25-08-2026 19:41, Riana Tauro wrote:
>>> SAF MHB errors are collected and classifed under Fabric error component
>>> by System controller. For SAF_MHB errors, if the cause is data
>>> payload parity error then log and return.
>>>
>>> For all other errors and causes, request a Secondary Bus Reset (SBR)
>>>
>>> Signed-off-by: Riana Tauro <riana.tauro@intel.com>
>>> ---
>>> drivers/gpu/drm/xe/xe_ras.c | 20 ++++++++++++++++++++
>>> drivers/gpu/drm/xe/xe_ras_types.h | 4 ++++
>>> 2 files changed, 24 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
>>> index d25d25f77531..586dc28a638a 100644
>>> --- a/drivers/gpu/drm/xe/xe_ras.c
>>> +++ b/drivers/gpu/drm/xe/xe_ras.c
>>> @@ -394,6 +394,23 @@ static u8 handle_device_memory_errors(struct xe_device *xe, struct xe_ras_error_
>>> return XE_RAS_RECOVERY_ACTION_RECOVERED;
>>> }
>>> +static u8 handle_fabric_errors(struct xe_device *xe, struct xe_ras_error_array *arr)
>>> +{
>>> + struct xe_ras_error_product *product = &arr->counter.product;
>>> + struct xe_ras_ieh_error *info = (void *)arr->details;
>>> +
>>> + if ((info->global_error_status & XE_RAS_FAB_IEH_SAF_MHB) &&
>>> + product->cause.cause == XE_RAS_FAB_CAUSE_PAYLOAD) {
>>> + xe_log_comp_recoverable(xe, FABRIC, &arr->counter, sizeof(arr->counter),
>>> + "SAF MHB error detected\n");
>>> + return XE_RAS_RECOVERY_ACTION_RECOVERED;
>>> + }
>>> +
>>> + xe_log_comp_fatal(xe, FABRIC, &arr->counter, sizeof(arr->counter),
>>> + "Other errors detected\n");
>> I think this also should go under recoverable.
> The point is that at this moment in time we don't know if the reset will
> indeed be able to recover the device.
I do not think it is right to say that, for any error we sure for know
what is the recovery needed. The respective error handler shall perform
that needed recovery action and anything that is recoverable by a driver
action is to be categorized under RECOVERABLE CPER severity.
The case where driver can't recover the device by itself falls into
FATAL case. Eg: probe failure or wedged cases.
Thanks,
Aravind.
> It is a moment where we are handling a global uncorrectable (fatal) error
> and we will return the reset action in a hope that the PCI subsystem will
> be able to perform an SBR to save the day and we start everything clean
> after that.
>
> So, I believe this approach is correct here.
>
> Aravind, thoughts?
>
>> Thanks,
>> Badal
>>
>>> + return XE_RAS_RECOVERY_ACTION_RESET;
>>> +}
>>> +
>>> void xe_ras_counter_threshold_crossed(struct xe_device *xe,
>>> struct xe_sysctrl_event_response *response)
>>> {
>>> @@ -555,6 +572,9 @@ enum xe_ras_recovery_action xe_ras_process_errors(struct xe_device *xe)
>>> case XE_RAS_COMP_DEVICE_MEMORY:
>>> action = handle_device_memory_errors(xe, arr);
>>> break;
>>> + case XE_RAS_COMP_FABRIC:
>>> + action = handle_fabric_errors(xe, arr);
>>> + break;
>>> default:
>>> /* For any other component, reset */
>>> action = XE_RAS_RECOVERY_ACTION_RESET;
>>> diff --git a/drivers/gpu/drm/xe/xe_ras_types.h b/drivers/gpu/drm/xe/xe_ras_types.h
>>> index 99b2466e2062..73517fd0d415 100644
>>> --- a/drivers/gpu/drm/xe/xe_ras_types.h
>>> +++ b/drivers/gpu/drm/xe/xe_ras_types.h
>>> @@ -12,6 +12,10 @@
>>> #define XE_RAS_NUM_ERROR_ARR 3
>>> /* Error bits in IEH global error status register */
>>> #define XE_RAS_SOC_IEH_PUNIT BIT(1)
>>> +/* Bits 16-31 represent individual SAF MHB unit */
>>> +#define XE_RAS_FAB_IEH_SAF_MHB GENMASK(31, 16)
> Riana, please share where I can check to help reviewing these bits.
>
> Thanks,
> Rodrigo.
>
>>> +/* Fabric Data payload parity errors */
>>> +#define XE_RAS_FAB_CAUSE_PAYLOAD BIT(2)
>>> /* Device memory error categories */
>>> #define XE_RAS_MEMORY_DB_ECC BIT(1)
>>> #define XE_RAS_MEMORY_POISON BIT(2)
next prev parent reply other threads:[~2026-08-27 10:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-25 14:11 [PATCH 0/2] Add error handling support for PCIe and fabric components Riana Tauro
2026-08-25 14:11 ` [PATCH 1/2] drm/xe/xe_ras: Add Fabric error handling Riana Tauro
2026-08-25 14:50 ` Nilawar, Badal
2026-08-26 21:00 ` Rodrigo Vivi
2026-08-27 10:55 ` Aravind Iddamsetty [this message]
2026-08-27 12:28 ` Rodrigo Vivi
2026-08-28 6:14 ` Tauro, Riana
2026-08-28 11:22 ` Mallesh, Koujalagi
2026-08-25 14:11 ` [PATCH 2/2] drm/xe/xe_ras: Add support for PCIe error component handling Riana Tauro
2026-08-28 11:02 ` Mallesh, Koujalagi
2026-08-25 14:18 ` ✓ CI.KUnit: success for Add error handling support for PCIe and fabric components Patchwork
2026-08-25 15:14 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-25 18:40 ` ✓ 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=6f8e5f5e-7bd8-4fef-b714-ef077f50812a@linux.intel.com \
--to=aravind.iddamsetty@linux.intel.com \
--cc=anshuman.gupta@intel.com \
--cc=aravind.iddamsetty@intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.com \
--cc=raag.jadav@intel.com \
--cc=ravi.kishore.koppuravuri@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=soham.purkait@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.