On Thu, 27 Oct 2016, Ville Syrjälä wrote: > On Thu, Oct 27, 2016 at 09:25:05PM +0200, Thomas Gleixner wrote: > > 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. > > Does the machine work, when you limit intel idle to C3, which would then > > match acpi idle ? > > I'm pretty sure I had tested all of these, but I just double checked > to make sure. There's no C3 with intel_idle so I limited to C2, but > that did not help. > > Isn't it possible that ACPI C3 is in fact C4? I thought ACPI C-states > are always numbered non-sparsely, and in this case ACPI C3 could be > anything from C3 to C11 (if the processor actually supported such > states obviously). Actually now that I look at the descriptions for > the states in sysfs, it says "MWAIT 0x30" for state3 on both drivers, > which I presume means it's in fact C4 for both. Indeed. Thanks, tglx
