Hi Raag,
On 14-05-2026 02:20 pm, Raag Jadav wrote:
On Tue, May 12, 2026 at 06:56:18PM +0530, Mallesh Koujalagi wrote:
When ``WEDGED=cold-reset`` is sent, it indicates that the device has
encountered an error condition that cannot be resolved through other
recovery methods such as driver rebind or bus reset, and requires a
complete device power cycle to restore functionality.
Signed-off-by: Mallesh Koujalagi <[email protected]>
---
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.
v5:
- Update commit message. (Raag)
- Remove unbind.
- Simplify cold-reset script.
---
Documentation/gpu/drm-uapi.rst | 64 +++++++++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 32206ce62931..809386f16521 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -422,7 +422,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`_
@@ -439,6 +439,7 @@ following expectations.
rebind unbind + bind driver
bus-reset unbind + bus reset/re-enumeration + bind
vendor-specific vendor specific recovery method
+ cold-reset remove device + slot power cycle + rescan
unknown consumer policy
=============== ========================================
@@ -451,6 +452,17 @@ 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 that the device has
+encountered an error condition that cannot be resolved through other
+recovery methods such as driver rebind or bus reset, and requires a complete
+device power cycle to restore functionality.
+
+This method is used by devices that are plugged directly into the PCIe slot
+which supports removing the power.
This looks good to me.
Vendor Specific Recovery
------------------------
@@ -528,6 +540,56 @@ 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=""
+ for addr_file in /sys/bus/pci/slots/*/address; do
This looks like we're peeking into every slot present on the machine which
is not very optimal. Can't we just follow device hierarchy in DEVPATH to
look for the slot that is relevant for us?
Agree! I will update example script by looking slot in DEVPATH instead
of scanning
every PCI slot on the system.
+ [ -f "$addr_file" ] || break
+ addr=$(cat "$addr_file" 2>/dev/null)
+ [ -n "$addr" ] || continue
+ case "$DEVICE" in
+ "$addr"*) SLOT=$(basename "$(dirname "$addr_file")"); break
;;
+ esac
+ done
+
+ if [ -n "$SLOT" ]; then
+ echo "Using slot $SLOT"
+
+ # Remove device
+ echo 1 > /sys/bus/pci/devices/$DEVICE/remove
+
+ # Power cycle slot
+ echo 0 > /sys/bus/pci/slots/$SLOT/power
+ sleep 2
Is this tested on actual machine? Is there an explanation for the amount
of sleep needed that serves all cases generically?
Honestly acknowledges! point, the original sleeps were guesses and
there is not a
single value that's correct across all the platforms (it's depends on
the slot controller,
downstream link etc.). I'll remove both sleeps in next version.
Thanks,
-/Mallesh
+ echo 1 > /sys/bus/pci/slots/$SLOT/power
+ sleep 1
Ditto.
Raag
+ # Rescan
+ echo 1 > /sys/bus/pci/rescan
+ echo "Done!"
+ else
+ echo "No slot found"
+ fi
+
Customization
-------------
--
2.34.1
