]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC 278325,280866:
authorjhb <jhb@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 15 Apr 2015 16:52:34 +0000 (16:52 +0000)
committerjhb <jhb@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Wed, 15 Apr 2015 16:52:34 +0000 (16:52 +0000)
commit7cb5b54b8392516dccd355545e229caf96025825
treea167dd4c1d22cb5924d6e131bbee411eb4fae9f5
parent44dd24db8bacf8becd3b01e9cf0e7471ca3984c9
MFC 278325,280866:
Revert the IPI startup sequence to match what is described in the
Intel Multiprocessor Specification v1.4.  The Intel SDM claims that

278325:
Revert the IPI startup sequence to match what is described in the
Intel Multiprocessor Specification v1.4.  The Intel SDM claims that
the INIT IPIs here are invalid, but other systems follow the MP
spec instead.

While here, fix the IPI wait routine to accept a timeout in microseconds
instead of a raw spin count, and don't spin forever during AP startup.
Instead, panic if a STARTUP IPI is not delivered after 20 us.

280866:
Wait 100 microseconds for a local APIC to dispatch each startup-related IPI
rather than 20.  The MP 1.4 specification states in Appendix B.2:

  "A period of 20 microseconds should be sufficient for IPI dispatch to
   complete under normal operating conditions".

(Note that this appears to be separate from the 10 millisecond (INIT) and
200 microsecond (STARTUP) waits after the IPIs are dispatched.)  The
Intel SDM is silent on this issue as far as I can tell.

At least some hardware requires 60 microseconds as noted in the PR, so
bump this to 100 to be on the safe side.

PR: 196542, 197756

git-svn-id: svn://svn.freebsd.org/base/stable/10@281560 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/amd64/amd64/mp_machdep.c
sys/i386/i386/mp_machdep.c
sys/x86/x86/local_apic.c