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 <a...@freebsd.org >> <mailto:a...@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 Gapon _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
