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]
Message-ID: <1271782601.25170.105.camel@laptop>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ