Date: Mon, 2 Apr 2018 16:27:08 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Bruce Evans <bde@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r327056 - in head/sys: kern sys x86/acpica x86/x86 Message-ID: <bd83adee-b631-3b4a-ece3-c5b7c863b9b3@FreeBSD.org> In-Reply-To: <201712210917.vBL9Hmd0042736@repo.freebsd.org> References: <201712210917.vBL9Hmd0042736@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21/12/2017 11:17, Bruce Evans wrote: > Author: bde > Date: Thu Dec 21 09:17:48 2017 > New Revision: 327056 > URL: https://svnweb.freebsd.org/changeset/base/327056 > > Log: > Use resume_cpus() instead of restart_cpus() to resume from ACPI suspension. Bruce, do you plan to merge this to stable/11 and maybe stable/10? If you'd like, I can do it. Unless you see any reason not to. > restart_cpus() worked well enough by accident. Before this set of fixes, > resume_cpus() used the same cpuset (started_cpus, meaning CPUs directed to > restart) as restart_cpus(). resume_cpus() waited for the wrong cpuset > (stopped_cpus) to become empty, but since mixtures of stopped and suspended > CPUs are not close to working, stopped_cpus must be empty when resuming so > the wait is null -- restart_cpus just allows the other CPUs to restart and > returns without waiting. > > Fix resume_cpus() to wait on a non-wrong cpuset for the ACPI case, and > add further kludges to try to keep it working for the XEN case. It > was only used for XEN. It waited on suspended_cpus. This works for > XEN. However, for ACPI, resuming is a 2-step process. ACPI has already > woken up the other CPUs and removed them from suspended_cpus. This > fix records the move by putting them in a new cpuset resuming_cpus. > Waiting on suspended_cpus would give the same null wait as waiting on > stopped_cpus. Wait on resuming_cpus instead. > > Add a cpuset toresume_cpus to map the CPUs being told to resume to keep > this separate from the cpuset started_cpus for mapping the CPUs being told > to restart. Mixtures of stopped and suspended/resuming CPUs are still far > from working. Describe new and some old cpusets in comments. > > Add further kludges to cpususpend_handler() to try to avoid breaking it > for XEN. XEN doesn't use resumectx(), so it doesn't use the second > return path for savectx(), and it goes from the suspended state directly > to the restarted state, while ACPI resume goes through the resuming state. > Enter the resuming state early for all cases so that resume_cpus can test > for being in this state and not have to worry about the intermediate > !suspended state for ACPI only. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bd83adee-b631-3b4a-ece3-c5b7c863b9b3>