On Mon, Nov 07, 2016 at 02:07:43PM +0100, Thomas Gleixner wrote:
> 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
Doesn't really seem to help. I did get a few random successes, but
mostly it just fails.
diff --git a/drivers/acpi/acpica/hwsleep.c b/drivers/acpi/acpica/hwsleep.c
index 3c9c10bd49e9..950319b619f1 100644
--- a/drivers/acpi/acpica/hwsleep.c
+++ b/drivers/acpi/acpica/hwsleep.c
@@ -44,6 +44,8 @@
#include <acpi/acpi.h>
#include <linux/acpi.h>
+#include <linux/pm-trace.h>
+#include <linux/delay.h>
#include "accommon.h"
#define _COMPONENT ACPI_HARDWARE
@@ -275,6 +277,8 @@ static enum hrtimer_restart acpi_hw_legacy_tmr(struct hrtimer *tmr)
{
hrtimer_forward_now(tmr, time10ms);
+ TRACE_RESUME(0);
+
return HRTIMER_RESTART;
}
@@ -327,14 +331,17 @@ acpi_status acpi_hw_legacy_wake(u8 sleep_state)
timer.function = acpi_hw_legacy_tmr;
hrtimer_start(&timer, time10ms, HRTIMER_MODE_REL);
+ TRACE_RESUME(0);
/*
* 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);
+ TRACE_RESUME(0);
hrtimer_cancel(&timer);
+ TRACE_RESUME(0);
/*
* Some BIOS code assumes that WAK_STS will be cleared on resume
* and use it to determine whether the system is rebooting or
Tossing that on top shows the trace before the _WAK being the last one
executed. Adding an msleep() before the _WAK does make the trace from
the timer handler show up so at least the timer seems to be ticking
up until some point.
--
Ville Syrjälä
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
