Date: Thu, 12 Sep 1996 23:45:57 -0700 From: erich@uruk.org To: Terry Lambert <terry@lambert.org> 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) Message-ID: <199609130645.XAA14621@uruk.org> In-Reply-To: Your message of "Thu, 12 Sep 1996 14:51:41 PDT." <199609122151.OAA07647@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert <terry@lambert.org> 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): <erich@uruk.org> Mad Genius wanna-be, CyberMuffin \__ (finger me for other stats) Web: http://www.uruk.org/~erich/ Motto: "I'll live forever or die trying"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609130645.XAA14621>