From: "Mallesh, Koujalagi" <mallesh.koujalagi@intel.com>
To: Raag Jadav <raag.jadav@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <riana.tauro@intel.com>,
<michal.wajdeczko@intel.com>, <matthew.d.roper@intel.com>
Subject: Re: [PATCH v1] drm/xe/ras: Fix boot-time ras error processing
Date: Mon, 3 Aug 2026 19:13:57 +0530 [thread overview]
Message-ID: <76fdd692-ed09-4316-8ec9-9fb3cd1d3e4c@intel.com> (raw)
In-Reply-To: <amyWumq3vnOYJLTf@black.igk.intel.com>
On 31-07-2026 06:06 pm, Raag Jadav wrote:
> On Thu, Jul 30, 2026 at 06:56:41PM +0530, Mallesh, Koujalagi wrote:
>> On 30-07-2026 04:36 pm, Raag Jadav wrote:
>>> Currently, we xe_ras_process_errors() inside xe_ras_init() to handle boot
>> Please add we "call" xe_ras_process_errors().
> It's used as a verb ;)
>
>>> time errors. But this can potentially result in declaring the device as
>>> wedged quite early in the driver load sequence, which is problematic due to
>>> the lack of registered drm device or required wedged cleanup hooks at this
>>> point.
>>>
>>> Call xe_ras_process_errors() only after the prerequisites are available.
>>>
>>> Fixes: d9732e498f5f ("drm/xe/xe_ras: Query errors from system controller on probe")
>>> Signed-off-by: Raag Jadav<raag.jadav@intel.com>
Working as per expectation.
Tested-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
>>> ---
>>> drivers/gpu/drm/xe/xe_device.c | 6 ++++++
>>> drivers/gpu/drm/xe/xe_ras.c | 6 ------
>>> 2 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
>>> index 03e6177a1d4c..47e1638d2ab3 100644
>>> --- a/drivers/gpu/drm/xe/xe_device.c
>>> +++ b/drivers/gpu/drm/xe/xe_device.c
>>> @@ -1149,6 +1149,12 @@ int xe_device_probe(struct xe_device *xe)
>>> if (err)
>>> goto err_unregister_display;
>>> + /*
>>> + * Process and log any errors detected by hardware. Possible results can
>>> + * include declaring the device as wedged, which must be done only after
>>> + * xe_device_wedged_fini() is registered.
>>> + */
>>> + xe_ras_process_errors(xe);
>> What happens when xe_device_declared_wedged()-->xe_pm_runtime_get_noresume
>> called before xe_pm_init()? Is it good to call xe_ras_process_errors
>>
>> function after xe_pm_init()? any thoughts.
> The usage count will increment regardless, which I guess is what we care
> about?
>
> Raag
>
>>> return devm_add_action_or_reset(xe->drm.dev, xe_device_sanitize, xe);
>>> err_unregister_display:
>>> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
>>> index 28123f08e513..db8bd19ad28b 100644
>>> --- a/drivers/gpu/drm/xe/xe_ras.c
>>> +++ b/drivers/gpu/drm/xe/xe_ras.c
>>> @@ -827,12 +827,6 @@ void xe_ras_init(struct xe_device *xe)
>>> if (IS_ENABLED(CONFIG_PCIEAER))
>>> ras_usp_aer_init(xe);
>>> - /*
>>> - * During probe, process and log any errors detected by firmware while the driver was not
>>> - * loaded. Critical errors such as Punit and CSC are reported through Pcode init failure,
>>> - * causing the driver to enter survivability mode.
>>> - */
>>> - xe_ras_process_errors(xe);
>>> ret = devm_device_add_group(xe->drm.dev, &gpu_health_group);
>>> if (ret)
>>> xe_err(xe, "Failed to create GPU health sysfs, err=%d\n", ret);
next prev parent reply other threads:[~2026-08-03 13:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 11:06 [PATCH v1] drm/xe/ras: Fix boot-time ras error processing Raag Jadav
2026-07-30 11:16 ` ✓ CI.KUnit: success for " Patchwork
2026-07-30 12:16 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-30 13:25 ` ✓ Xe.CI.FULL: " Patchwork
2026-07-30 13:26 ` [PATCH v1] " Mallesh, Koujalagi
2026-07-31 12:36 ` Raag Jadav
2026-08-03 13:43 ` Mallesh, Koujalagi [this message]
2026-07-30 17:03 ` Rodrigo Vivi
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=76fdd692-ed09-4316-8ec9-9fb3cd1d3e4c@intel.com \
--to=mallesh.koujalagi@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=matthew.d.roper@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=raag.jadav@intel.com \
--cc=riana.tauro@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.