I have to admit, this is not what I would have had.
Len Brown wrote:
On Tuesday 15 August 2006 01:37, [EMAIL PROTECTED] wrote:
From: William Morrrow <[EMAIL PROTECTED]>
This was discovered on a broken BIOS that simply returned from its suspend
procedure, appearing to the OS as a failed S3 attempt.
It is possible to invoke the protected mode register restore routine (which
would normally restore the sysenter registers) when the bios returns from
S3. This has no effect on a correctly running system and repairs the
damage from broken BIOS.
Where and why does acpi_enter_sleep_state() bail out?
Where?
It does not actually bail out, it just returns do_suspend_lowlevel as if
it did sleep.
It did sleep, but did not restart and return the call by the accepted
software mechanism.
The machine resumes execution in protected mode with the original
machine state
largely intact, but it fails to restore the sysenter/exit registers.
Why?
It is a sort of tortured bios. AMD shutdown the design center where the
development was occurring. Only one bios developer is left (not me), and
he is over-committed. Fixing our bios is not likely, since the facility
will
be closed before the mod can be created, tested, and deployed. I developed
this fix as a demonstration that the S3 can work in linux. The "fix" makes
error recovery stronger, and so it was suggested to push the fix since
it can
recover this and other more serious errors. There was concern that covering
errors was not a good idea in the first place, but in the end - the case
for more
reliability was stronger.
Does S3 work on windows on this box?
Yes (XP). This is the excuse - and is the force which is driving this
solution.
There is no test group to re-test all of the ACPI aware OSs S3 recovery.
So if they change (correct) the S3 strategy, it cant be well tested
here. Since it
was tested in the errant form and appeared to pass (on XP), there is
considerable
pressure to not correct the bios.
How does the machine fail without this patch -- does it crash or hang on
entering S3?
Does the patch below imply that we've got the return from acpi_enter_sleep_state
wrong no matter why it returns?
The machine goes into and out of S3 normally, and then flips out doing
double
faults on the first sysenter since these msrs are zeroed and not restored.
thanks,
-Len
If there are any other materials you need to evaluate this change, let
me know.
Thanks for your attention!
morrow
Signed-off-by: William Morrow <[EMAIL PROTECTED]>
Signed-off-by: Jordan Crouse <[EMAIL PROTECTED]>
Cc: "Yu, Luming" <[EMAIL PROTECTED]>
Cc: "Brown, Len" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
arch/i386/kernel/acpi/wakeup.S | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff -puN
arch/i386/kernel/acpi/wakeup.S~acpi-correctly-recover-from-a-failed-s3-attempt
arch/i386/kernel/acpi/wakeup.S
---
a/arch/i386/kernel/acpi/wakeup.S~acpi-correctly-recover-from-a-failed-s3-attempt
+++ a/arch/i386/kernel/acpi/wakeup.S
@@ -292,7 +292,10 @@ ENTRY(do_suspend_lowlevel)
pushl $3
call acpi_enter_sleep_state
addl $4, %esp
- ret
+
+# In case of S3 failure, we'll emerge here. Jump
+# to ret_point to recover
+ jmp ret_point
.p2align 4,,7
ret_point:
call restore_registers
_
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
