All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Mallesh Koujalagi" <mallesh.koujalagi@intel.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v11 3/3] drm/xe: Handle PUNIT errors by requesting cold-reset recovery
Date: Mon, 20 Jul 2026 10:48:15 +0000	[thread overview]
Message-ID: <20260720104816.51BD11F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260720101815.526813-8-mallesh.koujalagi@intel.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling `xe_device_declare_wedged()` during early driver probe fails to notify userspace because the DRM device is not yet registered in sysfs.
--

--- Patch [3]: [PATCH v11 3/3] drm/xe: Handle PUNIT errors by requesting cold-reset recovery ---
commit e4801339581daca0be0db10f90d94f25e72cfa52
Author: Mallesh Koujalagi <mallesh.koujalagi@intel.com>

drm/xe: Handle PUNIT errors by requesting cold-reset recovery

When PUNIT (power management unit) errors are detected that persist across
warm resets, mark the device as wedged with DRM_WEDGE_RECOVERY_COLD_RESET
and notify userspace that a complete device power cycle is required to
restore normal operation.

> diff --git a/drivers/gpu/drm/xe/xe_ras.c b/drivers/gpu/drm/xe/xe_ras.c
> index a31e06b8aa67a..92b4181026cbe 100644
> --- a/drivers/gpu/drm/xe/xe_ras.c
> +++ b/drivers/gpu/drm/xe/xe_ras.c
[ ... ]
> @@ -236,6 +236,12 @@ static u8 handle_core_compute_errors(struct xe_ras_error_array *arr)
>  	return XE_RAS_RECOVERY_ACTION_RECOVERED;
>  }
>  
> +static void punit_error_handler(struct xe_device *xe)
> +{
> +	xe_device_set_wedged_method(xe, DRM_WEDGE_RECOVERY_COLD_RESET);
> +	xe_device_declare_wedged(xe);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does calling xe_device_declare_wedged() here fail to notify userspace when
triggered during early driver probe?

If a PUNIT error is present at driver load, the call chain is:

xe_device_probe()
  xe_ras_init()
    xe_ras_process_errors()
      handle_soc_internal_errors()
        punit_error_handler()
          xe_device_declare_wedged()
            drm_dev_wedged_event()

Since drm_dev_register() has not yet been called at this stage of the probe
path, the sysfs directory for the DRM device does not exist, and the KOBJ_ADD
event has not been emitted.

Consequently, userspace (e.g., udev) will likely drop or ignore the KOBJ_CHANGE
uevent emitted by drm_dev_wedged_event().

Will this cause the device to finish probe successfully but leave userspace
unaware of the wedged state, breaking the automated cold reset recovery
mechanism?

> +}
> +
>  static u8 handle_soc_internal_errors(struct xe_device *xe, struct xe_ras_error_array *arr)
>  {
>  	struct xe_ras_soc_error *info = (void *)arr->details;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720101815.526813-5-mallesh.koujalagi@intel.com?part=3

  reply	other threads:[~2026-07-20 10:48 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 10:18 [PATCH v11 0/3] Introduce cold reset recovery method Mallesh Koujalagi
2026-07-20 10:18 ` [PATCH v11 1/3] drm: Add DRM_WEDGE_RECOVERY_COLD_RESET " Mallesh Koujalagi
2026-07-20 10:30   ` sashiko-bot
2026-07-20 10:18 ` [PATCH v11 2/3] drm/doc: Document " Mallesh Koujalagi
2026-07-20 10:18 ` [PATCH v11 3/3] drm/xe: Handle PUNIT errors by requesting cold-reset recovery Mallesh Koujalagi
2026-07-20 10:48   ` sashiko-bot [this message]
2026-07-21 17:37     ` Rodrigo Vivi
2026-07-20 14:30 ` ✓ CI.KUnit: success for Introduce cold reset recovery method (rev11) Patchwork
2026-07-20 15:05 ` ✓ Xe.CI.BAT: " Patchwork
2026-07-20 19:09 ` ✗ Xe.CI.FULL: failure " 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=20260720104816.51BD11F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=mallesh.koujalagi@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.