On Mon, 7 Nov 2016, Ville Syrjälä wrote:
> I didn't manage to find a lot of time to play around with this, but it
> definitely looks like the SMM trap is the problem here. I repeated my
> pm_trace experiemnts and when it gets stuck it is trying to execute the
> _WAK ACPI method which is where the SMM trap happens.
>
> Maybe the SMM code was written with the expectation of a periodic tick
> or something like that?
Can you try the untested hack below, please? It should confirm that.
Thanks,
tglx
8<---------------
--- a/drivers/acpi/acpica/hwsleep.c
+++ b/drivers/acpi/acpica/hwsleep.c
@@ -269,6 +269,17 @@ acpi_status acpi_hw_legacy_wake_prep(u8
return_ACPI_STATUS(status);
}
+static const ktime_t time10ms = { .tv64 = 10 * NSEC_PER_MSEC };
+
+static enum hrtimer_restart acpi_hw_legacy_tmr(struct hrtimer *tmr)
+{
+ hrtimer_forward_now(tmr, time10ms);
+
+ return HRTIMER_RESTART;
+}
+
+
+
/*******************************************************************************
*
* FUNCTION: acpi_hw_legacy_wake
@@ -284,6 +295,7 @@ acpi_status acpi_hw_legacy_wake_prep(u8
acpi_status acpi_hw_legacy_wake(u8 sleep_state)
{
+ struct hrtimer timer;
acpi_status status;
ACPI_FUNCTION_TRACE(hw_legacy_wake);
@@ -311,12 +323,18 @@ acpi_status acpi_hw_legacy_wake(u8 sleep
return_ACPI_STATUS(status);
}
+ hrtimer_init_on_stack(&timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ timer.function = acpi_hw_legacy_tmr;
+ hrtimer_start(&timer, time10ms, HRTIMER_MODE_REL);
+
/*
* Now we can execute _WAK, etc. Some machines require that the GPEs
* are enabled before the wake methods are executed.
*/
acpi_hw_execute_sleep_method(METHOD_PATHNAME__WAK, sleep_state);
+ hrtimer_cancel(&timer);
+
/*
* Some BIOS code assumes that WAK_STS will be cleared on resume
* and use it to determine whether the system is rebooting or
