Date: Tue, 31 Mar 2015 21:38:56 +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: <20150331183856.GT2379@kib.kiev.ua> In-Reply-To: <3149031.gmIvmB3vKt@ralph.baldwin.cx> References: <201503302013.t2UKDNCo093442@svn.freebsd.org> <20150331003850.GL2379@kib.kiev.ua> <3149031.gmIvmB3vKt@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 31, 2015 at 12:51:04PM -0400, John Baldwin wrote: > Also, I believe that the 100 millisecond timer referred to in step 14 above is > a timeout on the entire AP-enumeration process and is the timer waited for in > step 16. It also seems that the BIOS uses broadcast (all-but-self) IPIs, > whereas FreeBSD uses targeted (wake up a single AP at a time) IPIs. Yes, I also noted that when I tried to understand why x2APIC fails in AP startup sequence. > > I don't really know if we need to increase the delays or not. I have no idea > what Intel's source for those numbers in the two documents are. I don't think > I've ever seen a rationale for why they were chosen. It might beia time to run BIST + some sloppiness for the actual initialization code. Intel claims 9.1.2 Processor Built-In Self-Test (BIST) The overhead for performing a BIST varies between processor families. For example, the BIST takes approximately 30 million processor clock periods to execute on the Pentium 4 processor. This clock count is model-specific; Intel reserves the right to change the number of periods for any Intel 64 or IA-32 processor, without notification. > > BTW, Linux seems to use the equivalent of 100 milliseconds for the > lapic_ipi_wait() stage before doing the other delays (see > native_safe_apic_wait_icr_idle() for the non-X2APIC case). My main observation is that we allow almost twice as much time for AP to start in the xAPIC mode vs. x2APIC. But increasing the delays did not helped the machines where it fails.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150331183856.GT2379>