Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 17 May 2018 08:56:59 +0100
From:      Johannes Lundberg <johalun0@gmail.com>
To:        Andriy Gapon <avg@freebsd.org>
Cc:        freebsd-current <freebsd-current@freebsd.org>
Subject:   Re: Lag after resume culprit found
Message-ID:  <CAECmPwuKoQaD0M-wJagns_YCDMLy_qMnuy%2BceLF5UZtfE_1ehg@mail.gmail.com>
In-Reply-To: <CAECmPwsgQhMM6zu=EfV=DQ4VHzEMuQUjD%2B45O-TP=A2U9mM8Qg@mail.gmail.com>
References:  <CAECmPwtULDe9GGK0PhnUa7_n=zxripJj9nh5m0RTF9XqKhXKYQ@mail.gmail.com> <acaa419d-891e-96b1-7c1f-3203857c07ec@FreeBSD.org> <CAECmPwsgQhMM6zu=EfV=DQ4VHzEMuQUjD%2B45O-TP=A2U9mM8Qg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 17, 2018 at 8:46 AM, Johannes Lundberg <johalun0@gmail.com>
wrote:

>
>
> On Thu, May 17, 2018 at 7:43 AM, Andriy Gapon <avg@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
>>
>
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAECmPwuKoQaD0M-wJagns_YCDMLy_qMnuy%2BceLF5UZtfE_1ehg>