From owner-cvs-all@FreeBSD.ORG Fri Mar 10 10:20:17 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A79916A420; Fri, 10 Mar 2006 10:20:17 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6CD243D45; Fri, 10 Mar 2006 10:20:09 +0000 (GMT) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id k2AAK2BJ057652; Fri, 10 Mar 2006 13:20:02 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id k2AAK1WY057651; Fri, 10 Mar 2006 13:20:02 +0300 (MSK) (envelope-from yar) Date: Fri, 10 Mar 2006 13:20:01 +0300 From: Yar Tikhiy To: John Baldwin Message-ID: <20060310102001.GX4474@comp.chem.msu.su> References: <200603091623.k29GNFf9003993@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603091623.k29GNFf9003993@repoman.freebsd.org> User-Agent: Mutt/1.5.9i Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/i386 mpapic.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2006 10:20:17 -0000 On Thu, Mar 09, 2006 at 04:23:15PM +0000, John Baldwin wrote: > jhb 2006-03-09 16:23:15 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_4) > sys/i386/i386 mpapic.c > Log: > Revert the previous change. Even though Intel insists that the behavior > this change restores is wrong, it turns out the "proper" method is worse > in practice for existing machines. This is probably due to the fact that > using fixed priority with a physical broadcast destination effectively > broadcasts interrupts to all CPUs. Fixing that would require a lot more > work than just restoring the previous "incorrect" behavior and would > probably be riskier as well. > > PR: kern/94160 > Reported by: Richard Wiwatowski rjwiwat at internode dot on dot net > > Revision Changes Path > 1.37.2.9 +3 -3 src/sys/i386/i386/mpapic.c This problem cannot affect a kernel unless it has been built with "options SMP", can it? Thanks! -- Yar