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: [email protected] > 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 ? _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "[email protected]"
