Date: Tue, 31 Mar 2015 03:38:50 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r280866 - in head/sys: amd64/amd64 i386/i386 Message-ID: <20150331003850.GL2379@kib.kiev.ua> In-Reply-To: <201503302013.t2UKDNCo093442@svn.freebsd.org> References: <201503302013.t2UKDNCo093442@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150331003850.GL2379>