Re: [RFC/PATCH] ACPI: Correctly recover from a failed S3 attempt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

> We have a poorly behaving BIOS that simply returns from its suspend
> procedure, rather then jumping to the restart routine indicated by
> the FACS.  This appears to Linux as a failed S3 attempt.
> 
> This would normally succeed, but the sysenter msrs are not
> restored and the restart fails.  It is not clear if this is the only
> omission, but if the sysenter msrs are manually entered in the debugger, 
> the OS resumes.
> 
> The attached patch would invoke the register restore function on failure.
> This has absolutely no effect on correct systems, and, "does the right thing"
> for failed or stupid BIOSes, at least as far as I am concerned.

Can we get fixed bios, too?

What machines are affected?

> --- a/arch/i386/kernel/acpi/wakeup.S
> +++ b/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

%esp manipulation is now unneccessary?

Can we somehow propagate the error condition?

Why jmp when ret_point is next instruction?

>  ret_point:
>  	call	restore_registers


-- 
Thanks for all the (sleeping) penguins.
-
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

[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux