2 files changed, 36 insertions, 0 deletions

diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index 2875f1f74a07..194ca446ac28 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -99,9 +99,38 @@ Description:
 
                 dmesg -s 1000000 | grep 'hash matches'
 
+                If you do not get any matches (or they appear to be false
+                positives), it is possible that the last PM event point
+                referred to a device created by a loadable kernel module.  In
+                this case cat /sys/power/pm_trace_dev_match (see below) after
+                your system is started up and the kernel modules are loaded.
+
                 CAUTION: Using it will cause your machine's real-time (CMOS)
                 clock to be set to a random invalid time after a resume.
 
+What;           /sys/power/pm_trace_dev_match
+Date:           October 2010
+Contact:        James Hogan <james@albanarts.com>
+Description:
+                The /sys/power/pm_trace_dev_match file contains the name of the
+                device associated with the last PM event point saved in the RTC
+                across reboots when pm_trace has been used.  More precisely it
+                contains the list of current devices (including those
+                registered by loadable kernel modules since boot) which match
+                the device hash in the RTC at boot, with a newline after each
+                one.
+
+                The advantage of this file over the hash matches printed to the
+                kernel log (see /sys/power/pm_trace), is that it includes
+                devices created after boot by loadable kernel modules.
+
+                Due to the small hash size necessary to fit in the RTC, it is
+                possible that more than one device matches the hash, in which
+                case further investigation is required to determine which
+                device is causing the problem.  Note that genuine RTC clock
+                values (such as when pm_trace has not been used), can still
+                match a device and output it's name here.
+
 What:           /sys/power/pm_async
 Date:           January 2009
 Contact:        Rafael J. Wysocki <rjw@sisk.pl>
diff --git a/Documentation/power/s2ram.txt b/Documentation/power/s2ram.txt
index 514b94fc931e..1bdfa0443773 100644
--- a/Documentation/power/s2ram.txt
+++ b/Documentation/power/s2ram.txt
@@ -49,6 +49,13 @@ machine that doesn't boot) is:
    device (lspci and /sys/devices/pci* is your friend), and see if you can
    fix it, disable it, or trace into its resume function.
 
+   If no device matches the hash (or any matches appear to be false positives),
+   the culprit may be a device from a loadable kernel module that is not loaded
+   until after the hash is checked. You can check the hash against the current
+   devices again after more modules are loaded using sysfs:
+
+        cat /sys/power/pm_trace_dev_match
+
 For example, the above happens to be the VGA device on my EVO, which I
 used to run with "radeonfb" (it's an ATI Radeon mobility). It turns out
 that "radeonfb" simply cannot resume that device - it tries to set the