Hi!
> > 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;
> }
...
> 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.
But it returns to kernel... can you use more trace points to figure
out where it hangs?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
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
