From owner-freebsd-smp Thu Sep 12 23:48:50 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id XAA25623 for smp-outgoing; Thu, 12 Sep 1996 23:48:50 -0700 (PDT) Received: from uruk.org (uruk.org [198.145.95.253]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id XAA25609 for ; Thu, 12 Sep 1996 23:48:37 -0700 (PDT) From: erich@uruk.org Received: from loopback (loopback [127.0.0.1]) by uruk.org (8.7.4/8.7.3) with SMTP id XAA14621; Thu, 12 Sep 1996 23:45:58 -0700 (PDT) Message-Id: <199609130645.XAA14621@uruk.org> X-Authentication-Warning: uruk.org: Host loopback [127.0.0.1] didn't use HELO protocol To: Terry Lambert cc: smp@csn.net, peter@spinner.dialix.com, rv@groa.uct.ac.za, freebsd-smp@freebsd.org Subject: Re: (long) Intel SMP info (was -> Re: Intel XXpress - some SMP benchmarks) In-reply-to: Your message of "Thu, 12 Sep 1996 14:51:41 PDT." <199609122151.OAA07647@phaeton.artisoft.com> Date: Thu, 12 Sep 1996 23:45:57 -0700 Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Terry Lambert writes: > > > 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"? There were two sections to the "rules" I mentioned. One was the above, for "default" configurations which have only 2 CPUs and a fixed layout. The second was when the MP Configuration Table is used. The only rule it had was that one of the CPUs must have APIC id #0. > > 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. Sure. The problem I mentioned was an exclusive condition. Either: -- Only send a startup sequence (which resets a CPU's APIC id to the hardware id) at system startup time, or -- Don't reassign APIC ids. If you do both, then the temporary confusion when a CPU is restarted and before it can boot up far enough to set the APIC id to the different value is a serious race condition in interprocessor interrupts sent to that APIC id number. -- Erich Stefan Boleyn \_ E-mail (preferred): Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying"