Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 26 Oct 2002 11:00:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 26 Oct 2002 11:00:02 -0400 Received: from franka.aracnet.com ([216.99.193.44]:47839 "EHLO franka.aracnet.com") by vger.kernel.org with ESMTP id ; Sat, 26 Oct 2002 11:00:01 -0400 Date: Sat, 26 Oct 2002 08:03:45 -0700 From: "Martin J. Bligh" Reply-To: "Martin J. Bligh" To: Alan Cox , Dave Jones cc: Alan Cox , Linux Kernel Mailing List Subject: Re: [PATCH] Double x86 initialise fix. Message-ID: <3007933349.1035619425@[10.10.2.3]> In-Reply-To: <3007712682.1035619204@[10.10.2.3]> References: <3007712682.1035619204@[10.10.2.3]> X-Mailer: Mulberry/2.1.2 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1046 Lines: 27 >>> Isn't this always the case on x86 ? >>> /me waits to hear gory details of some IBM monster. >> >> It isnt. The boot CPU may be any number. In addition you can strap dual >> pentium boxes to arbitrate for who is boot cpu (this is used for fault >> tolerance). > > Eh? I don't understand this, and I think Dave is right for all the > IBM monsters I know of ;-) The *apicid* may not be 0 but the CPU > numbers are dynamically assigned as we boot, so the boot CPU will > always get 0, surely? Indeed cscope indicates these are acutally hardcoded into the calls: 1 smpboot.c smp_callin 418 smp_store_cpu_info(cpuid); 2 smpboot.c smp_boot_cpus 989 smp_store_cpu_info(0); The only thing that does smp_callin is a secondary ... so the boot CPU has this hardcoded to 0 ... I think Dave's fine. M. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/