On 21-04-2026 02:00 pm, Raag Jadav wrote:
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? ;)
I'll revert it as per last rev.
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 <[email protected]>
---
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?
Yes, you are right, when we remove the device unbind is not required.
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?
I'll revert it as per last rev.
+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?
Sure
+ 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?
It's nor required. I'll remove those lines.
Thanks,
-/Mallesh
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
