linux-kernel - Re: [PATCH] ACPI: DMI init_set_sci_en_on_resume for multiple Lenovo ThinkPads

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 20 Apr 2010 11:56:41 -0500
From:	Jerone Young <jerone.young@...onical.com>
To:	Alex Chiang <achiang@...onical.com>
Cc:	lenb@...nel.org, colin.king@...onical.com,
	linux-acpi@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>, stable@...nel.org
Subject: Re: [PATCH] ACPI: DMI init_set_sci_en_on_resume for multiple
 Lenovo ThinkPads

Don't think this patch should go in as Lenovo is issuing a BIOS to
address this issue. On these Thinkpads listed and more. Seems to add
uneeded quirks in my opinion.

Though some over all patch may be good for all machines. As Windows
seems to be setting this bit on it's own.

				Jerone

On Tue, 2010-04-20 at 08:03 -0600, Alex Chiang wrote:
> Multiple Lenovo ThinkPad models with Intel Core i5/i7 CPUs can
> successfully suspend/resume once, and then hang on the second s/r
> cycle.
> 
> We got confirmation that this was due to a BIOS defect. The BIOS
> did not properly set SCI_EN coming out of S3. The BIOS guys
> hinted that The Other Leading OS ignores the fact that hardware
> owns the bit and sets it manually.
> 
> In any case, an existing DMI table exists for machines where this
> defect is a known problem. Lenovo promise to fix their BIOS, but
> for folks who either won't or can't upgrade their BIOS, allow
> Linux to workaround the issue.
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=15407
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/532374
> 
> Confirmed by numerous testers in the launchpad bug that using
> acpi_sleep=sci_force_enable fixes the issue. We add the machines
> to acpisleep_dmi_table[] to automatically enable this workaround.
> 
> Cc: stable@...nel.org
> Cc: Colin King <colin.king@...onical.com>
> Signed-off-by: Alex Chiang <achiang@...onical.com>
> ---
> diff --git a/drivers/acpi/sleep.c b/drivers/acpi/sleep.c
> index f74834a..ce54cd0 100644
> --- a/drivers/acpi/sleep.c
> +++ b/drivers/acpi/sleep.c
> @@ -450,6 +450,46 @@ static struct dmi_system_id __initdata acpisleep_dmi_table[] = {
>  		},
>  	},
>  	{
> +	.callback = init_set_sci_en_on_resume,
> +	.ident = "Lenovo ThinkPad T410",
> +	.matches = {
> +		DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T410"),
> +		},
> +	},
> +	{
> +	.callback = init_set_sci_en_on_resume,
> +	.ident = "Lenovo ThinkPad T510",
> +	.matches = {
> +		DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T510"),
> +		},
> +	},
> +	{
> +	.callback = init_set_sci_en_on_resume,
> +	.ident = "Lenovo ThinkPad W510",
> +	.matches = {
> +		DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W510"),
> +		},
> +	},
> +	{
> +	.callback = init_set_sci_en_on_resume,
> +	.ident = "Lenovo ThinkPad X201",
> +	.matches = {
> +		DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201"),
> +		},
> +	},
> +	{
> +	.callback = init_set_sci_en_on_resume,
> +	.ident = "Lenovo ThinkPad X201",
> +	.matches = {
> +		DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> +		DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"),
> +		},
> +	},
> +	{
>  	.callback = init_old_suspend_ordering,
>  	.ident = "Panasonic CF51-2L",
>  	.matches = {
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/