Re: [PATCH v3 5/5] drm/xe/ras: Move xe_ras_process_errors() to xe_ras

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Moving xe_ras_process_errors() earlier in the probe sequence causes WEDGED uevents to be silently dropped and GT-level wedging to be skipped.
- [Medium] Moving xe_ras_process_errors() to xe_ras_init() behind the xe->info.has_sysctrl check breaks fault injection for non-sysctrl platforms.
--

commit 09bf5945b56af88ea485174674cf6523adc4c2a4
Author: Raag Jadav <raag.jadav@intel.com>

drm/xe/ras: Move xe_ras_process_errors() to xe_ras

This commit moves the execution of xe_ras_process_errors() from the end
of xe_device_probe() into xe_ras_init().

> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> index 12279ed276297..8b0ea8a48d57b 100644
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c

[ ... ]

> @@ -1148,13 +1148,6 @@ int xe_device_probe(struct xe_device *xe)
>  
>  	detect_preproduction_hw(xe);
>  
> -	/*
> -	 * Process and log any errors detected by hardware. Possible results can
> -	 * include declaring the device as wedged, which must be done only after
> -	 * xe_wedge_fini() is registered.
> -	 */
> -	xe_ras_process_errors(xe);
> -
>  	err = devm_add_action_or_reset(xe->drm.dev, xe_device_sanitize, xe);

> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
> index 2e8eb8856f97b..abf4800ff1e36 100644
> --- a/drivers/gpu/drm/xe/xe_ras.c
> +++ b/drivers/gpu/drm/xe/xe_ras.c

[ ... ]

> @@ -933,6 +933,13 @@ 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);

[Severity: High]
Does moving this call into xe_ras_init() cause WEDGED uevents to be silently
dropped and GT-level wedging to be skipped?

Because xe_ras_init() runs early in the probe sequence, before xe_gt_init()
and drm_dev_register() have executed, a boot-time hardware error detected
here (or fault injection) triggers xe_wedge_declare() prematurely.

This synchronously calls xe_gt_wedge_declare() while gt->wedge.worker.func
is still NULL, causing GT wedging to be skipped entirely. Additionally, the
async wedge_work races with drm_dev_register(), leading kobject_uevent_env()
to silently drop the uevent because the DRM device is not yet exposed in
sysfs.

This leaves the device in a partially wedged state where GT components like
GuC continue running, and userspace is not notified of the wedged state.

[Severity: Medium]
Does placing this call behind the xe->info.has_sysctrl check break fault
injection for non-sysctrl platforms?

Earlier in xe_ras_init(), there is an early return:

	if (!xe->info.has_sysctrl)
		return;

Prior to this patch, xe_ras_process_errors() was called unconditionally in
xe_device_probe(), meaning the cold-reset wedge fault injection
(xe_fault_wedge_cold_reset) could be triggered on any platform. Now, the
sysctrl early return bypasses xe_ras_process_errors() entirely on platforms
without sysctrl, which causes a regression in the testing infrastructure.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260907083541.2194747-1-raag.jadav@intel.com?part=5