"Rafael J. Wysocki" <rjw@xxxxxxx> writes:
> Second, you can use PM_TRACE (Documentation/power/s2ram.txt) to find the
> place where it really fails.
First I augmented my minimal config kernel with some TRACE_RESUME()s:
--- a/kernel/power/main.c 2007-05-27 23:48:05.000000000 +0200
+++ b/kernel/power/main.c 2007-06-03 22:28:46.000000000 +0200
@@ -223,6 +223,7 @@
pr_debug("PM: Finishing wakeup.\n");
suspend_finish(state);
Unlock:
+ TRACE_RESUME(error);
mutex_unlock(&pm_mutex);
return error;
}
@@ -303,6 +304,7 @@
error = enter_state(state);
else
error = -EINVAL;
+ TRACE_RESUME(error);
return error ? error : n;
}
With this test script:
#! /bin/sh
sync
echo 1 >/sys/power/pm_trace
echo mem >/sys/power/state
shutdown -rn now
I got alternating
hash matches drivers/base/power/resume.c:58
and
hash matches kernel/power/main.c:307
> First, you can check if the patch
>
> http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.22-rc3/patches/20-ACPI-preserve-the-ebx-value-in-acpi_copy_wakeup_routine.patch
Then I applied this patch, but it doesn't change anything.
But either way the script never reaches "shutdown -rn now". So, it
seems, that my laptop does a full resume every other reboot, but it
never returns to userspace.
> Also, please read Documentation/power/basic-pm-debugging.txt .
Regards, Olaf.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
