Greetings, I also hit this issue on the recently released Toshiva Kirabook. I bisected the v3.3->v3.4 change (with the help of patching in the kvm clock fix as needed) and tracked it down to this commit:
commit 2feec47d4c5f80b05f1650f5a24865718978eea4
Author: Bob Moore <email address hidden>
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 <email address hidden>
Signed-off-by: Len Brown <email address hidden>
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);
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 reasonabley well. I'm not sure what the apropriate fix is, maybe a blacklist of devices that provide the new registers but don't implement them properly? I'll also post this to the linux-acpi list to see if anyone there offers advice.
Greetings, I also hit this issue on the recently released Toshiva Kirabook. I bisected the v3.3->v3.4 change (with the help of patching in the kvm clock fix as needed) and tracked it down to this commit:
commit 2feec47d4c5f80b 05f1650f5a24865 718978eea4
Author: Bob Moore <email address hidden>
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 <email address hidden>
Signed-off-by: Len Brown <email address hidden>
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) ; status) ) {
sleep_ type_value =
(( acpi_gbl_ sleep_type_ a << ACPI_X_ SLEEP_TYPE_ POSITION) &
ACPI_ X_SLEEP_ TYPE_MASK) ;
if (ACPI_SUCCESS(
}
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 reasonabley well. I'm not sure what the apropriate fix is, maybe a blacklist of devices that provide the new registers but don't implement them properly? I'll also post this to the linux-acpi list to see if anyone there offers advice.