From: Raag Jadav <raag.jadav@intel.com>
To: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
Cc: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
rodrigo.vivi@intel.com, andrealmeid@igalia.com,
christian.koenig@amd.com, airlied@gmail.com,
simona.vetter@ffwll.ch, mripard@kernel.org,
anshuman.gupta@intel.com, badal.nilawar@intel.com,
riana.tauro@intel.com, karthik.poosa@intel.com,
sk.anirban@intel.com
Subject: Re: [PATCH v4 3/4] drm/doc: Document DRM_WEDGE_RECOVERY_COLD_RESET recovery method
Date: Tue, 21 Apr 2026 10:30:56 +0200 [thread overview]
Message-ID: <aec1wAFHMZyb9sFW@black.igk.intel.com> (raw)
In-Reply-To: <20260413133013.560239-9-mallesh.koujalagi@intel.com>
On Mon, Apr 13, 2026 at 07:00:17PM +0530, Mallesh Koujalagi wrote:
> When ``WEDGED=cold-reset`` is sent, it indicates a non-recoverable
This looks like "cold-reset" should be able to recover it, so is it
really non-recoverable? ;)
> device error, only a full power cycle can restore the device.
>
> v2:
> - Add several instead of number to avoid update. (Jani)
>
> v3:
> - Update document with generic scenario. (Riana)
> - Consistent with terminology. (Raag)
> - Remove already covered information.
>
> v4:
> - Update doc. (Raag/Riana)
> - Change commit message. (Raag)
>
> Signed-off-by: Mallesh Koujalagi <mallesh.koujalagi@intel.com>
> ---
> Documentation/gpu/drm-uapi.rst | 60 +++++++++++++++++++++++++++++++++-
> 1 file changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 579e87cb9ff7..0b87c8ed760d 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -418,7 +418,7 @@ needed.
> Recovery
> --------
>
> -Current implementation defines four recovery methods, out of which, drivers
> +Current implementation defines several recovery methods, out of which, drivers
> can use any one, multiple or none. Method(s) of choice will be sent in the
> uevent environment as ``WEDGED=<method1>[,..,<methodN>]`` in order of less to
> more side-effects. See the section `Vendor Specific Recovery`_
> @@ -435,6 +435,7 @@ following expectations.
> rebind unbind + bind driver
> bus-reset unbind + bus reset/re-enumeration + bind
> vendor-specific vendor specific recovery method
> + cold-reset unbind + remove device + slot power cycle + rescan
Do you need to unbind if you're already removing the device?
> unknown consumer policy
> =============== ========================================
>
> @@ -447,6 +448,14 @@ debug purpose in order to root cause the hang. This is useful because the first
> hang is usually the most critical one which can result in consequential hangs
> or complete wedging.
>
> +Cold Reset Recovery
> +-------------------
> +
> +When ``WEDGED=cold-reset`` is sent, it indicates a non-recoverable device error,
> +only a full power cycle can restore the device.
This was phrased much better in last rev, not sure why changed?
> +This method is used by devices that are plugged directly into the PCIe slot.
... which supports removing the power.
> Vendor Specific Recovery
> ------------------------
>
> @@ -524,6 +533,55 @@ Recovery script::
> echo -n $DEVICE > $DRIVER/unbind
> echo -n $DEVICE > $DRIVER/bind
>
> +Example - cold-reset
> +--------------------
> +
> +Udev rule::
> +
> + SUBSYSTEM=="drm", ENV{WEDGED}=="cold-reset", DEVPATH=="*/drm/card[0-9]",
> + RUN+="/path/to/cold-reset.sh $env{DEVPATH}"
> +
> +Recovery script::
> +
> + #!/bin/sh
> +
> + [ -z "$1" ] && echo "Usage: $0 <device-path>" && exit 1
> +
> + # Get device
> + DEVPATH=$(readlink -f /sys/$1/device 2>/dev/null || readlink -f /sys/$1)
> + DEVICE=$(basename $DEVPATH)
> +
> + echo "Cold reset: $DEVICE"
> +
> + # Try slot power reset first
> + SLOT=$(find /sys/bus/pci/slots/ -type l 2>/dev/null | while read slot; do
> + ADDR=$(cat "$slot" 2>/dev/null)
> + [ -n "$ADDR" ] && echo "$DEVICE" | grep -q "^$ADDR" && basename $(dirname "$slot") && break
> + done)
This looks like too much is happening here, can we try to simplify a bit?
> + if [ -n "$SLOT" ]; then
> + echo "Using slot $SLOT"
> +
> + # Unbind driver
> + [ -e "/sys/bus/pci/devices/$DEVICE/driver" ] && \
> + echo "$DEVICE" > /sys/bus/pci/devices/$DEVICE/driver/unbind 2>/dev/null
Is this really needed?
Raag
> + # Remove device
> + echo 1 > /sys/bus/pci/devices/$DEVICE/remove
> +
> + # Power cycle slot
> + echo 0 > /sys/bus/pci/slots/$SLOT/power
> + sleep 2
> + echo 1 > /sys/bus/pci/slots/$SLOT/power
> + sleep 1
> +
> + # Rescan
> + echo 1 > /sys/bus/pci/rescan
> + echo "Done!"
> + else
> + echo "No slot found"
> + fi
> +
> Customization
> -------------
>
> --
> 2.34.1
>
next prev parent reply other threads:[~2026-04-21 8:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-13 13:30 [PATCH v4 0/4] Introduce cold reset recovery method Mallesh Koujalagi
2026-04-13 13:30 ` [PATCH v4 1/4] Introduce Xe Uncorrectable Error Handling Mallesh Koujalagi
2026-04-13 13:30 ` [PATCH v4 2/4] drm: Add DRM_WEDGE_RECOVERY_COLD_RESET recovery method Mallesh Koujalagi
2026-04-21 8:19 ` Raag Jadav
2026-04-13 13:30 ` [PATCH v4 3/4] drm/doc: Document " Mallesh Koujalagi
2026-04-21 8:30 ` Raag Jadav [this message]
2026-05-12 8:29 ` Mallesh, Koujalagi
2026-04-13 13:30 ` [PATCH v4 4/4] drm/xe: Handle PUNIT errors by requesting cold-reset recovery Mallesh Koujalagi
2026-04-21 9:11 ` Raag Jadav
2026-04-13 17:43 ` ✗ CI.checkpatch: warning for Introduce cold reset recovery method (rev3) Patchwork
2026-04-13 17:44 ` ✓ CI.KUnit: success " Patchwork
2026-04-13 18:45 ` ✓ Xe.CI.BAT: " Patchwork
2026-04-13 21:22 ` ✗ 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=aec1wAFHMZyb9sFW@black.igk.intel.com \
--to=raag.jadav@intel.com \
--cc=airlied@gmail.com \
--cc=andrealmeid@igalia.com \
--cc=anshuman.gupta@intel.com \
--cc=badal.nilawar@intel.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=karthik.poosa@intel.com \
--cc=mallesh.koujalagi@intel.com \
--cc=mripard@kernel.org \
--cc=riana.tauro@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona.vetter@ffwll.ch \
--cc=sk.anirban@intel.com \
/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.