Cc: Rafael J. Wysocki <rjw@...>, Alan Stern <stern@...>, Nigel Cunningham <nigel@...>, <nigel@...>, Kexec Mailing List <kexec@...>, <linux-kernel@...>, Eric W. Biederman <ebiederm@...>, Huang, Ying <ying.huang@...>, <linux-pm@...>, huang ying <huang.ying.caritas@...>, Andrew Morton <akpm@...>
On Sep 21, 2007, at 17:16:59, Jeremy Maitin-Shepard wrote:
I think that in order for this to work, there would need to be some
ABI whereby the resume-ing kernel can pass its entire ACPI state and
a bunch of other ACPI-related device details to the resume-ed kernel,
which I believe it does not do at the moment. I believe that what
causes problems is the ACPI state data that the kernel stores is
*different* between identical sequential boots, especially when you
add/remove/replace batteries, AC, etc.
Since we currently throw away most of that in-kernel ACPI interpreter
state data when we load the to-be-resumed image and replace it with
the state from the previous boot it looks to the ACPI code and
firmware like our system's hardware magically changed behind its
back. The result is that the ACPI and firmware code is justifiably
confused (although probably it should be more idempotent to begin
with). There's 2 potential solutions:
1) Formalize and copy a *lot* of ACPI state from the resume-ing
kernel to the resume-ed kernel.
2) Properly call the ACPI S4 methods in the proper order
Neither one is particularly easy or particularly pleasant, especially
given all the vendor bugs in this general area. Theoretically we
should be able to do both, since one will be more reliable than the
other on different systems depending on what kinds of firmware bugs
they have.
Cheers,
Kyle Moffett
-
