On Thu, May 17, 2018 at 8:46 AM, Johannes Lundberg <johal...@gmail.com> wrote:
> > > On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon <a...@freebsd.org> wrote: > >> On 17/05/2018 02:07, Johannes Lundberg wrote: >> > https://github.com/freebsd/freebsd/commit/66f063557f257baa9c >> 8aeab9f933171eaa6e1cfa >> > 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. > > I did some further testing. Calling CPU_CLR_ATOMIC(cpu, &suspended_cpus); before pmap_init_pat(); is what "breaks" resume. Is this Intel only or this it happen on AMD as well (which this patch was intended for)? >> > 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"