svn commit: r280866 - in head/sys: amd64/amd64 i386/i386
Konstantin Belousov
kostikbel at gmail.com
Tue Mar 31 00:39:00 UTC 2015
On Mon, Mar 30, 2015 at 08:13:23PM +0000, John Baldwin wrote:
> Author: jhb
> Date: Mon Mar 30 20:13:22 2015
> New Revision: 280866
> URL: https://svnweb.freebsd.org/changeset/base/280866
>
> Log:
> 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: 197756
> Reported by: zaphod at berentweb.com
> MFC after: 1 week
>
> Modified:
> head/sys/amd64/amd64/mp_machdep.c
> head/sys/i386/i386/mp_machdep.c
>
> Modified: head/sys/amd64/amd64/mp_machdep.c
> ==============================================================================
> --- head/sys/amd64/amd64/mp_machdep.c Mon Mar 30 20:01:41 2015 (r280865)
> +++ head/sys/amd64/amd64/mp_machdep.c Mon Mar 30 20:13:22 2015 (r280866)
> @@ -1084,7 +1084,7 @@ ipi_startup(int apic_id, int vector)
> */
> lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_LEVEL |
> APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_INIT, apic_id);
> - lapic_ipi_wait(20);
> + lapic_ipi_wait(100);
>
> /* Explicitly deassert the INIT IPI. */
> lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_LEVEL |
> @@ -1104,7 +1104,7 @@ ipi_startup(int apic_id, int vector)
> lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE |
> APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP |
> vector, apic_id);
> - if (!lapic_ipi_wait(20))
> + if (!lapic_ipi_wait(100))
> panic("Failed to deliver first STARTUP IPI to APIC %d",
> apic_id);
> DELAY(200); /* wait ~200uS */
> @@ -1118,7 +1118,7 @@ ipi_startup(int apic_id, int vector)
> lapic_ipi_raw(APIC_DEST_DESTFLD | APIC_TRIGMOD_EDGE |
> APIC_LEVEL_ASSERT | APIC_DESTMODE_PHY | APIC_DELMODE_STARTUP |
> vector, apic_id);
> - if (!lapic_ipi_wait(20))
> + if (!lapic_ipi_wait(100))
> panic("Failed to deliver second STARTUP IPI to APIC %d",
> apic_id);
I initially thought that some x2APIC issues, which are still not
understood, are related to changed timing, and esp. to the fact that
lapic_ipi_wait() is nop for x2APIC mode. I have the patch that increased
all DELAYs, in particular, the delays after the lapic_ipi_wait()s, by two
times.
But apparently, that did not helped, and it seems that there are
sporadic reports of Linux having similar issues with x2APIC on similar
mobile SandyBridge, which are proof-less charged to BIOS bugs.
Mostly, my question is, should we increase DELAYS() in addition to
lapic_ipi_wait() timeouts ?
More information about the svn-src-head
mailing list