From: sashiko-bot@kernel.org
To: "Raag Jadav" <raag.jadav@intel.com>, intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v9 7/7] drm/xe/ras: Move xe_ras_process_errors() to xe_ras
Date: Fri, 16 Oct 2026 03:36:24 +0000 [thread overview]
Message-ID: <sashiko-outbox-173680@kernel.org> (raw)
In-Reply-To: <20261016031559.427941-8-raag.jadav@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm/xe: early wedging from ras drops uevent and aborts probe
--
commit 4c0f3e5505fa3f5df25ea28082e7cca0e36630d7
Author: Raag Jadav <raag.jadav@intel.com>
drm/xe/ras: Move xe_ras_process_errors() to xe_ras
This commit moves xe_ras_process_errors() back to xe_ras_init(), reverting
a previous change now that xe_wedge_fini() is handled earlier in the probe.
> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
> index 0072bb4cc5dfe..db3cbc186a514 100644
> --- a/drivers/gpu/drm/xe/xe_ras.c
> +++ b/drivers/gpu/drm/xe/xe_ras.c
> @@ -1212,6 +1212,13 @@ int xe_ras_init(struct xe_device *xe)
> get_offline_list(xe);
> get_offline_queue(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 to xe_ras_init() early in the probe sequence cause
issues when encountering a critical error?
If xe_ras_process_errors() finds a critical error, it declares the device
wedged, which schedules wedged.work.
This work calls drm_dev_wedged_event() which sends a uevent. However, since
drm_dev_register() has not yet run at this point, the kobject is not
in sysfs and the uevent will be silently dropped.
Furthermore, will declaring the device wedged this early cause subsequent
probe steps to fail? For example:
xe_gt_init()
xe_uc_load_hw()
xe_guc_pc_start()
pc_action_reset()
xe_guc_ct_send()
xe_guc_ct_send() will return -ENOTRECOVERABLE instead of -ECANCELED
because the device is wedged. This error propagates up, completely aborting
xe_device_probe(), causing the driver to unbind rather than entering
survivability mode as intended.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261016031559.427941-1-raag.jadav@intel.com?part=7
next prev parent reply other threads:[~2026-10-16 3:36 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 3:15 [PATCH v9 0/7] Introduce xe_wedge Raag Jadav
2026-10-16 3:15 ` [PATCH v9 1/7] drm/xe/gt: Use GT ordered workqueue for wedging Raag Jadav
2026-10-16 3:32 ` sashiko-bot
2026-10-16 3:15 ` [PATCH v9 2/7] drm/xe: Drop xe_device_set_wedged_method() Raag Jadav
2026-10-16 3:15 ` [PATCH v9 3/7] drm/xe: Move xe_device_wedged_fini() registration to xe_device_probe_early() Raag Jadav
2026-10-16 3:15 ` [PATCH v9 4/7] drm/xe: Make xe_device_declare_wedged() IRQ safe Raag Jadav
2026-10-16 3:28 ` sashiko-bot
2026-10-16 3:15 ` [PATCH v9 5/7] drm/xe/pci_error: Flush GT wedge worker before bus reset Raag Jadav
2026-10-16 3:33 ` sashiko-bot
2026-10-16 3:15 ` [PATCH v9 6/7] drm/xe: Introduce xe_wedge Raag Jadav
2026-10-16 3:15 ` [PATCH v9 7/7] drm/xe/ras: Move xe_ras_process_errors() to xe_ras Raag Jadav
2026-10-16 3:36 ` sashiko-bot [this message]
2026-10-16 3:22 ` ✗ CI.checkpatch: warning for Introduce xe_wedge (rev8) Patchwork
2026-10-16 3:25 ` ✓ CI.KUnit: success " Patchwork
2026-10-16 4:03 ` ✓ Xe.CI.BAT: " Patchwork
2026-10-16 13:02 ` ✓ 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=sashiko-outbox-173680@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=raag.jadav@intel.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox