On 17/05/2018 10:56, Andriy Gapon wrote: > On 17/05/2018 10:46, Johannes Lundberg wrote: >> On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon <avg_at_freebsd.org >> <mailto:avg_at_freebsd.org>> wrote: >> >> On 17/05/2018 02:07, Johannes Lundberg wrote: >> > https://github.com/freebsd/freebsd/commit/66f063557f257baa9c8aeab9f933171eaa6e1cfa >> <https://github.com/freebsd/freebsd/commit/66f063557f257baa9c8aeab9f933171eaa6e1cfa> >> > x86 cpususpend_handler: call wbinvd after setting suspend state bits >> >> That's very interesting and surprising. >> That commit changes something that happens before suspend, it should not have >> any effect on the system state after resume. >> >> Does anyone have a theory of what could be wrong? >> >> Nope but moving >> CPU_CLR_ATOMIC(cpu, &suspended_cpus); >> back to the end of that scope fixes it. > > That's interesting. > Thank you for testing it! > And let me think about it. Oh, I am stupid. I intended that operation to be right after the CPU is done with restoring its saved context. Which means that it has to be after fpuresume/npxresume block. Could you please re-test with CPU_CLR_ATOMIC(cpu, &suspended_cpus) at that position? And my apologies. >> > How to test (i915kms) >> > >> > Start X with glxgears >> > Confirm running stable at 60 fps >> > suspend/resume (S3) >> > glxgears is now fluctuating between 10-40 fps. > -- Andriy GaponReceived on Thu May 17 2018 - 05:59:52 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:16 UTC