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: sta...@kernel.org
Cc: Colin King <colin...@canonical.com>
Signed-off-by: Alex Chiang <ach...@canonical.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-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> 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.
While this is certainly the low impact fix for now, I'd prefer the patch
I sent as a long-term solution in order to avoid having to add more
machines to the table in future.
--
Matthew Garrett | mj...@srcf.ucam.org
Ah, yes, I should have been more clear.
I want to get this patch upstream so we can get it into stable,
so that we can get it into Ubuntu 10.04.
Certainly what I'm proposing is suitable for stable: it's
minimal, specific to a few machines, etc.
For the long term, I support the patch that Matthew sent out
yesterday, and we can perhaps think about removing the quirks
entirely.
Thanks,
/ac
Though some over all patch may be good for all machines. As Windows
seems to be setting this bit on it's own.
Jerone
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
It's a perfectly safe workaround that's limited to a well-bounded set of
machines and fixes a pretty serious problem with them. While I'd prefer
my approach and then a removal of the existing quirk entries, Alex's
patch makes more sense for stable. The BIOS update is as yet unreleased,
requires either Windows or an optical drive (which some of these
machines don't have) and is a far from discoverable solution to the
issue.
--
Matthew Garrett | mj...@srcf.ucam.org
I could agree, but the only issue is if you go to the thinkpad-acpi or
ibm-acpi mailing list they would probably disagree as there have been
updates to the bios in the past required for proper functionality of
Thinkpads ;-) .. the bios update methods have not changed since then for
Thinkpads.
Thanks,
Jerone
Sure, we'll let Len decide if he wants to take it or not. I'm ok
with that.
> Though some over all patch may be good for all machines. As Windows
> seems to be setting this bit on it's own.
Yes, that's what Matthew's patch does.
http://thread.gmane.org/gmane.linux.acpi.devel/45635
/ac
> I could agree, but the only issue is if you go to the thinkpad-acpi or
> ibm-acpi mailing list they would probably disagree as there have been
> updates to the bios in the past required for proper functionality of
> Thinkpads ;-) .. the bios update methods have not changed since then for
> Thinkpads.
If another OS works, and if Linux can be made to work without impairing
the functionality of working machines, then Linux should be made to
work. Always. Updating the BIOS should be limited to cases where it's
impossible to fix things up in the OS.
--
Matthew Garrett | mj...@srcf.ucam.org
Agreed.
Rafael
Whoops, not only is the .ident line wrong for the second entry
above (should be X201s), it's also extraneous, as the first entry
will catch it.
I'll resubmit.
/ac
hopefully we'll figure out how to safely nuke this DMI list shortly.
thanks,
Len Brown, Intel Open Source Technology Center
Whoops, you picked up the v1, not the v2 version.
The v2 version is a little shorter; it elides the X201S entry
because the X201 entry will catch it.
Doesn't affect functionality / correctness. It's just a little
superfluous to have the 2nd entry.
fyi,
/ac