On Wednesday, May 22, 2013 11:35:43 PM Moore, Robert wrote: > This should be fixed in ACPICA version 20130518 Since that's not a new regression, that should be fine, but we need to remember to mark that patch for inclusion into the -stable kernels. Thanks, Rafael > > -----Original Message----- > > From: Rafael J. Wysocki [mailto:rjw@xxxxxxx] > > Sent: Wednesday, May 22, 2013 12:37 PM > > To: Moore, Robert > > Cc: Michael Marineau; linux-acpi@xxxxxxxxxxxxxxx; Len Brown; Zheng, Lv > > Subject: Re: ACPI v5 sleep registers broken on Toshiba laptops > > > > Hi Bob, > > > > What do you think about this? > > > > Rafael > > > > > > On Wednesday, May 22, 2013 09:39:12 AM Michael Marineau wrote: > > > Greetings, > > > > > > On the recently released Toshiba Kirabook and kernels >= 3.4 > > > suspend/resume only works once. After resume input from things like > > > the power button, brightness buttons, lid switch, etc. no longer work > > > and the laptop simply hangs when suspended for a second time. This > > > appears to also impact other recent Toshiba laptops (although the bug > > > claims the hang is during the second resume rather than the second > > > suspend as is my case). > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1094800 > > > > > > Suspend/resume and all the buttons work just fine on v3.3. I bisected > > > the v3.3->v3.4 change (with the help of patching in a kvm clock fix as > > > needed) and tracked it down to this commit: > > > > > > commit 2feec47d4c5f80b05f1650f5a24865718978eea4 > > > Author: Bob Moore <robert.moore@xxxxxxxxx> > > > Date: Tue Feb 14 15:00:53 2012 +0800 > > > > > > ACPICA: ACPI 5: Support for new FADT SleepStatus, SleepControl > > > registers > > > > > > Adds sleep and wake support for systems with these registers. > > > One new file, hwxfsleep.c > > > > > > Signed-off-by: Bob Moore <robert.moore@xxxxxxxxx> > > > Signed-off-by: Len Brown <len.brown@xxxxxxxxx> > > > > > > Specifically, when the sleep status/control registeres are detected > > > they are used instead of the traditional registers. The failure to > > > resume a second time is triggered by this write in the new > > > acpi_hw_extended_wake_prep function: > > > > > > status = acpi_get_sleep_type_data(ACPI_STATE_S0, > > > &acpi_gbl_sleep_type_a, > > > &acpi_gbl_sleep_type_b); > > > if (ACPI_SUCCESS(status)) { > > > sleep_type_value = > > > ((acpi_gbl_sleep_type_a << ACPI_X_SLEEP_TYPE_POSITION) & > > > ACPI_X_SLEEP_TYPE_MASK); > > > > > > (void)acpi_write((u64)(sleep_type_value | ACPI_X_SLEEP_ENABLE), > > > &acpi_gbl_FADT.sleep_control); > > > } > > > > > > Replacing that write with the corresponding code from > > > acpi_hw_legacy_wake_prep while leaving the other acpi_hw_extended_* > > > functions alone gets suspend/resume working consistantly. That isn't > > > quite enough as events don't seem to get re-enabled so acpi buttons > > > and such don't work after resume. Copying the enable power button code > > > from acpi_hw_legacy_wake to acpi_hw_extended_wake at least gets the > > > power button back but lid, brightness, etc remain dead. > > > > > > At the moment I've hacked these changes into v3.10.0-rc2 along with > > > another hack to fix a video regression and it seems to behave > > > reasonably well (minus the brightness keys and lid). I'm not sure what > > > the apropriate fix is. Maybe find some way beyond their presence to > > > detect if these registers are safe to use or just a device blacklist? > > > > > > > > > > -- > > I speak only for myself. > > Rafael J. Wysocki, Intel Open Source Technology Center. > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
