Cc: Jeremy Maitin-Shepard <jbms@...>, 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 22, 2007, at 06:34:17, Rafael J. Wysocki wrote:
First of all, we will need to make the resumed kernel throw away
*ALL* of its ACPI state on S5 and completely reinitialize ACPI as
though it was booting for the first time on resume. From what I can
tell, we "throw away" all the ACPI state in the boot kernel and
reinitialize it there, but then the reinitialized state is
overwritten with the resumed kernel's state and the two don't always
happen to be the same. (Like if a battery got replaced or AC status
changed).
Umm, I don't see how that can possibly work properly. For a laptop,
for example, the restore kernel will need to access the disk, the LCD
display, and possibly the AC/battery and current CPU frequency. From
what I understand of ACPI, both of the former may need ACPI code to
operate properly (Isn't there an ATA taskfile object of some kind?)
and the latter two almost definitely need ACPI. Ergo the boot kernel
may need to initialize and use ACPI just to run an ATA taskfile so it
can read from the HDD efficiently.
That's not what he was talking about. The problem discussed was:
(A) You hibernate your box, entering S5 (IE: power off)
(B) You resume the box and the boot kernel inits all the ACPI stuff.
(C) The boot kernel's ACPI state is completely replaced by the
resumed kernel's state.
(D) Hardware stops working mysteriously because of ACPI problems.
The only possible conclusion is that the state between the boot
kernel and the resume kernel was *different* and so the device failed
because the ACPI state in the resume kernel doesn't match the actual
state of the hardware.
Cheers,
Kyle Moffett
-