From owner-freebsd-smp Thu Sep 12 14:55:18 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA05973 for smp-outgoing; Thu, 12 Sep 1996 14:55:18 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA05967 for ; Thu, 12 Sep 1996 14:55:14 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA07647; Thu, 12 Sep 1996 14:51:42 -0700 From: Terry Lambert Message-Id: <199609122151.OAA07647@phaeton.artisoft.com> Subject: Re: (long) Intel SMP info (was -> Re: Intel XXpress - some SMP benchmarks) To: erich@uruk.org Date: Thu, 12 Sep 1996 14:51:41 -0700 (MST) Cc: terry@lambert.org, smp@csn.net, peter@spinner.dialix.com, rv@groa.uct.ac.za, freebsd-smp@freebsd.org In-Reply-To: <199609122113.OAA13651@uruk.org> from "erich@uruk.org" at Sep 12, 96 02:13:44 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I suspect that you will need to inventory the processors, then back-fill > > the holes for the case where you would get an ID collision during the > > shuffling -- ie: if I have n processors, all APIC ID's < (n-1) are left > > alone, and only the remainder are rewritten. > > > > I *believe* that the BP is guranteed an APIC ID of 0. > > No. The rules are: > > "default configuration": > CPUs must be numbered consecutively starting with 0, in any order. The XXPRESS fails this, then, since it goes 0, 2 (not 0, 1). Does consecutively mean "insreasing" as opposed to "increasing monotonically"? > Also realize that when a processor goes through INIT, the APIC id will be > reset to the hardware id. This means if your OS is in the middle of doing > a bunch of things and then sends an INIT to one of the CPUs, you have a big > potential problem there. To solve this, you either don't reassign APIC ids, > or never send an INIT when the system is up and running. Or you can reassign ID's, as long as you back fill holes instead of shifting them down. That way an ID can never collide with a reassigned ID following an INIT. You just have to be prepared to deal with INIT by taking the ID and remapping it back into the backfill location. The reason we are talking about backfilling or renumbering at all is because the XXPRESS is known to fail the "consecutiveness" test already... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.