From owner-freebsd-stable@FreeBSD.ORG Mon Aug 13 17:47:17 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 898D31065672 for ; Mon, 13 Aug 2012 17:47:17 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5D7FC8FC19 for ; Mon, 13 Aug 2012 17:47:17 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id AE483B95D; Mon, 13 Aug 2012 13:47:16 -0400 (EDT) From: John Baldwin To: freebsd-stable@freebsd.org Date: Mon, 13 Aug 2012 12:34:53 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p17; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201208131234.53905.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 13 Aug 2012 13:47:16 -0400 (EDT) Cc: "mnln.l4" Subject: Re: Kernel panic at early boot time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Aug 2012 17:47:17 -0000 On Wednesday, August 08, 2012 8:26:56 pm mnln.l4 wrote: > I finally have some time to take a closer look at this issue. Yes, it > is caused by SMI#. DragonflyBSD has tried to fix the similar problem > (see http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/bb467734fc407e2c2de7f8314c63dd9f708f4df4) > > But Windows and Linux don't cause such problem on my machine. > > I compared MP initialization code between FreeBSD, Linux and NetBSD. I > believe the problem is FreeBSD doesn't wait for 10ms between IPI_INIT > assert and IPI_INIT deassert (though FreeBSD waits for 10ms after > IPI_INIT deassert). After inserting 10ms wait time, the issue is > solved. BTW, Intel's MP spec 1.4 doesn't explain very well either. I think the confusion is that we have an extra IPI step (deassert INIT IPI) that we did have the wait after. Your patch is correct and I've committed it (well, a variant, I put the DELAY() after the lapic_ipi_wait()). I think we should actually just remove the deassert INIT IPI entirely as I can find no reference in either the MP spec or otherwise that says that it should be used. It is also ignored on all modern processors. -- John Baldwin