Date: Sun, 29 Sep 1996 03:22:14 -0600 From: Steve Passe <smp@csn.net> To: Peter Wemm <peter@freefall.freebsd.org> Cc: freebsd-smp@freefall.freebsd.org Subject: Re: cvs commit: sys/kern init_main.c kern_shutdown.c Message-ID: <199609290922.DAA17778@clem.systemsix.com> In-Reply-To: Your message of "Sun, 29 Sep 1996 01:36:28 PDT." <199609290836.BAA13518@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Peter said: > Modified: kern init_main.c kern_shutdown.c > Log: > Attempt to fix the boot() problems in obtaining cpu#0, as pointed out > by: Hidetoshi Shimokawa <simokawa@sat.t.u-tokyo.ac.jp> > > I'm not 100% sure I've got this right, cpunumber() now returns a logical > cpu id, doesn't it? Steve?? Therefore, the boot cpu logical id is always > zero, right?? :-) yes, this is correct. The BSP (Boot Strap Processor) is always logical #0. APs (Application Processors) follow in logical order 1,2,3,n. These are the numbers returned by 'cpunumber()' and 'GETPROCID()'. If you need the actual APIC ID of a logical CPU, use 'CPU_TO_ID( logical# )'. Inversly, to get the logical # from an APIC ID use 'ID_TO_CPU( physical# )'. These values are now parsed from the MP table during boot, supporting machines with SPARSE and/or un-ordered CPU/IO APIC ID numbering (most P6 machines). It also supports non-standard APIC addresses. Note that we are a long way from supporting more than 2 CPUs, ie. if you try to set NCPU=4 it will probably go down in flames. I'll check the patch in a moment and confirm. -- Steve Passe | powered by smp@csn.net | FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609290922.DAA17778>