From: Raag Jadav <raag.jadav@intel.com>
To: Riana Tauro <riana.tauro@intel.com>
Cc: intel-xe@lists.freedesktop.org, anshuman.gupta@intel.com,
rodrigo.vivi@intel.com, aravind.iddamsetty@linux.intel.com,
badal.nilawar@intel.com, ravi.kishore.koppuravuri@intel.com,
mallesh.koujalagi@intel.com
Subject: Re: [PATCH v2 08/11] drm/xe/xe_ras: Add support for Uncorrectable Core-Compute errors
Date: Wed, 4 Mar 2026 17:52:33 +0100 [thread overview]
Message-ID: <aahjUV9VPkT11a85@black.igk.intel.com> (raw)
In-Reply-To: <20260302102155.4074630-21-riana.tauro@intel.com>
On Mon, Mar 02, 2026 at 03:52:03PM +0530, Riana Tauro wrote:
> Uncorrectable Core-Compute errors are classified into Global and Local
> errors.
>
> Global error is an error that affects the entire device requiring a
> reset. This type of error is not isolated. When an AER is reported and
> error_detected is invoked return PCI_ERS_RESULT_NEED_RESET.
>
> A Local error is confined to a specific component or context like a
> engine. These errors can be contained and recovered by resetting
> only the affected part without distrupting the rest of the device.
>
> Upon detection of an Uncorrectable Local Core-Compute error, an AER is
> generated and GuC is notified of the error. The KMD then sets
> the context as non-runnable and initiates an engine reset.
> (TODO: GuC <->KMD communication for the error).
TODOs are more useful in the code, so we can actually find them ;)
> Since the error is contained and recovered, PCI error handling
> callback returns PCI_ERS_RESULT_RECOVERED.
...
> +enum xe_ras_recovery_action xe_ras_process_errors(struct xe_device *xe)
> +{
> + struct xe_sysctrl_mailbox_command command = {0};
> + struct xe_ras_get_error_response response;
> + enum xe_ras_recovery_action final_action;
> + size_t rlen;
> + int ret;
> +
> + /* Default action */
> + final_action = XE_RAS_RECOVERY_ACTION_RECOVERED;
> +
> + if (!xe->info.has_sysctrl)
> + return XE_RAS_RECOVERY_ACTION_RESET;
> +
> + xe_ras_prepare_sysctrl_command(&command, XE_SYSCTRL_CMD_GET_SOC_ERROR, NULL, 0,
> + &response, sizeof(response));
> +
> + do {
> + memset(&response, 0, sizeof(response));
> + rlen = 0;
> +
> + ret = xe_sysctrl_send_command(xe, &command, &rlen);
> + if (ret || !rlen) {
We'd probably want them to be separate cases so we know what actually
happened. Besides, I think !rlen is redundant here since you're already
handling it below.
> + xe_err(xe, "[RAS]: Sysctrl error ret %d\n", ret);
> + goto err;
> + }
> +
> + if (rlen != sizeof(response)) {
> + xe_err(xe, "[RAS]: Sysctrl response does not match len!!\n");
I'd print rlen as well.
> + goto err;
> + }
> +
> + if (response.num_errors > XE_RAS_NUM_ERROR_ARR) {
I'd handle this as part of for loop below so we atleast have the chance
to recover based on initial errors.
> + xe_err(xe, "[RAS]: Number of errors out of bound (%d)\n",
> + XE_RAS_NUM_ERROR_ARR);
> + goto err;
> + }
> +
> + for (int i = 0; i < response.num_errors; i++) {
for (int i = 0; i < response.num_errors && i < XE_RAS_NUM_ERROR_ARR; i++)
> + struct xe_ras_error_array arr = response.error_arr[i];
> + enum xe_ras_recovery_action action;
> + struct xe_ras_error_class error_class;
> + u8 component;
> +
> + error_class = arr.error_class;
> + component = error_class.common.component;
> +
> + switch (component) {
> + case XE_RAS_COMPONENT_CORE_COMPUTE:
> + action = handle_compute_errors(xe, &arr);
> + break;
> + default:
> + xe_err(xe, "[RAS]: Unknown error component %u\n", component);
> + break;
> + }
> +
> + /*
> + * Retain the highest severity action. Process and log all errors
> + * and then take appropriate recovery action
Punctuations.
> + */
> + if (action > final_action)
> + final_action = action;
> + }
> +
> + } while (response.additional_errors);
I know we're not NASA but I'd try to have some timeout instead of blindly
trusting the hardware.
Raag
> + return final_action;
> +
> +err:
> + return XE_RAS_RECOVERY_ACTION_RESET;
> +}
next prev parent reply other threads:[~2026-03-04 16:52 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-02 10:21 [PATCH v2 00/11] Introduce Xe Uncorrectable Error Handling Riana Tauro
2026-03-02 10:21 ` [PATCH v2 01/11] drm/xe/xe_sysctrl: Add System controller patch Riana Tauro
2026-03-02 10:21 ` [PATCH v2 02/11] drm/xe/xe_survivability: Decouple survivability info from boot survivability Riana Tauro
2026-03-02 17:00 ` Raag Jadav
2026-03-03 8:18 ` Mallesh, Koujalagi
2026-03-30 12:56 ` Tauro, Riana
2026-03-30 13:00 ` Tauro, Riana
2026-03-02 10:21 ` [PATCH v2 03/11] drm/xe/xe_pci_error: Implement PCI error recovery callbacks Riana Tauro
2026-03-02 17:37 ` Raag Jadav
2026-03-03 5:09 ` Riana Tauro
2026-03-04 10:38 ` Mallesh, Koujalagi
2026-03-31 5:18 ` Tauro, Riana
2026-03-02 10:21 ` [PATCH v2 04/11] drm/xe/xe_pci_error: Group all devres to release them on PCIe slot reset Riana Tauro
2026-03-02 10:22 ` [PATCH v2 05/11] drm/xe: Skip device access during PCI error recovery Riana Tauro
2026-03-04 10:59 ` Mallesh, Koujalagi
2026-03-02 10:22 ` [PATCH v2 06/11] drm/xe/xe_ras: Initialize Uncorrectable AER Registers Riana Tauro
2026-03-02 10:22 ` [PATCH v2 07/11] drm/xe/xe_ras: Add structures and commands for Uncorrectable Core Compute Errors Riana Tauro
2026-03-04 16:32 ` Raag Jadav
2026-03-31 16:14 ` Tauro, Riana
2026-04-01 6:25 ` Raag Jadav
2026-04-01 6:39 ` Tauro, Riana
2026-03-02 10:22 ` [PATCH v2 08/11] drm/xe/xe_ras: Add support for Uncorrectable Core-Compute errors Riana Tauro
2026-03-04 16:52 ` Raag Jadav [this message]
2026-03-06 18:37 ` Raag Jadav
2026-03-31 16:24 ` Tauro, Riana
2026-04-01 6:34 ` Raag Jadav
2026-04-01 6:47 ` Tauro, Riana
2026-03-06 3:50 ` [v2,08/11] " Purkait, Soham
2026-03-31 16:16 ` Tauro, Riana
2026-03-02 10:22 ` [PATCH v2 09/11] drm/xe/xe_ras: Add structures for SoC Internal errors Riana Tauro
2026-03-10 13:02 ` Mallesh, Koujalagi
2026-03-11 14:51 ` Riana Tauro
2026-03-02 10:22 ` [PATCH v2 10/11] drm/xe/xe_ras: Handle Uncorrectable " Riana Tauro
2026-03-10 13:29 ` Mallesh, Koujalagi
2026-03-11 14:55 ` Riana Tauro
2026-03-02 10:22 ` [PATCH v2 11/11] drm/xe/xe_pci_error: Process errors in mmio_enabled Riana Tauro
2026-03-11 7:10 ` Mallesh, Koujalagi
2026-03-11 14:39 ` Riana Tauro
2026-03-12 8:08 ` Mallesh, Koujalagi
2026-03-02 16:10 ` ✗ CI.checkpatch: warning for Introduce Xe Uncorrectable Error Handling (rev2) Patchwork
2026-03-02 16:11 ` ✓ CI.KUnit: success " Patchwork
2026-03-02 16:48 ` ✓ Xe.CI.BAT: " Patchwork
2026-03-02 18:29 ` ✗ Xe.CI.FULL: failure " 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=aahjUV9VPkT11a85@black.igk.intel.com \
--to=raag.jadav@intel.com \
--cc=anshuman.gupta@intel.com \
--cc=aravind.iddamsetty@linux.intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=mallesh.koujalagi@intel.com \
--cc=ravi.kishore.koppuravuri@intel.com \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@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.