All of lore.kernel.org
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-10-16  3:36 UTC|newest]

Thread overview: 15+ 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

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 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.