Re: [PATCH v1] drm/xe/ras: Fix boot-time ras error processing

"Mallesh, Koujalagi" <[email protected]> Mon, 3 Aug 2026 19:13:57 +0530
Newsgroups org.freedesktop.lists.intel-xe
Message-ID <[email protected]>
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<[email protected]>

Working as per expectation.

Tested-by: Mallesh Koujalagi <[email protected]>

>>> ---
>>>    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);