From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: <sashiko-reviews@lists.linux.dev>
Cc: Mallesh Koujalagi <mallesh.koujalagi@intel.com>,
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v11 3/3] drm/xe: Handle PUNIT errors by requesting cold-reset recovery
Date: Tue, 21 Jul 2026 13:37:56 -0400 [thread overview]
Message-ID: <al-udBqjgYOGgzja@intel.com> (raw)
In-Reply-To: <20260720104816.51BD11F00A3A@smtp.kernel.org>
On Mon, Jul 20, 2026 at 10:48:15AM +0000, sashiko-bot@kernel.org wrote:
> 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?
Mallesh, could you please add a fault-inject test to this flow here and
ensure that we are indeed getting the notification we are willing to get?
It looks that right now we are really never getting the uevent that we
are willing to get.
Thanks,
Rodrigo.
>
> > +}
> > +
> > 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
next prev parent reply other threads:[~2026-07-21 17:38 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
2026-07-21 17:37 ` Rodrigo Vivi [this message]
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=al-udBqjgYOGgzja@intel.com \
--to=rodrigo.vivi@intel.com \
--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.