Date: Thu, 12 Sep 1996 14:51:41 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: erich@uruk.org Cc: terry@lambert.org, 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: <199609122151.OAA07647@phaeton.artisoft.com> In-Reply-To: <199609122113.OAA13651@uruk.org> from "erich@uruk.org" at Sep 12, 96 02:13:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609122151.OAA07647>