On Fri, 28 Oct 2016, Ville Syrjälä wrote:

On Thu, Oct 27, 2016 at 10:41:18PM +0200, Thomas Gleixner wrote:

quoted

On Thu, 27 Oct 2016, Ville Syrjälä wrote:

quoted

On Thu, Oct 27, 2016 at 09:25:05PM +0200, Thomas Gleixner wrote:

quoted

So it would be interesting whether that hunk in resume_broadcast() is
sufficient.

So far it looks like the answer is yes.

Looks to be about 5 seconds slower than acpi-idle in resuming, but
I suppose that's not all that surprising ;)

Well, set it to 1msec then. If that works reliably then we really can do
that unconditionally. There is no harm in firing a useless timer during
resume once.

I narrowed down the required timeout, and looks like 25ms is the
minimum that works. With 24ms I already started to have failures. So
maybe just bump it up by an order of magnitude to 250ms for some
safety margin?

Sure, but what puzzles me is that we need a timeout that big. What happens
between broadcast_resume() and broadcast_resume() + 25ms?

IOW, what is the event/resume function which we need to bridge. We should
really try to track than down.

You might try to enable function tracing and do a tracing_off() when that
25ms timeout fires.

Something like 

	stop_trace = true;

in broadcast_resume() and then in the broadcast timer function:

	if (stop_trace) {
		stop_trace = false;
		tracing_off();
	}

Then when the machine is up read the trace, compress and upload it
somewhere or send it in private mail if it's not that big.

Thanks,

	tglx