Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 26 Feb 2003 17:42:03 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 26 Feb 2003 17:42:03 -0500 Received: from franka.aracnet.com ([216.99.193.44]:20685 "EHLO franka.aracnet.com") by vger.kernel.org with ESMTP id ; Wed, 26 Feb 2003 17:42:02 -0500 Date: Wed, 26 Feb 2003 14:51:07 -0800 From: "Martin J. Bligh" To: Linus Torvalds , Ion Badulescu cc: Rusty Russell , linux-kernel@vger.kernel.org, mingo@redhat.com Subject: Re: [BUG] 2.5.63: ESR killed my box! Message-ID: <3420000.1046299866@[10.10.2.4]> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Linux/x86) 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: 1663 Lines: 34 > Wouldn't it be nicer to just fix the write instead? I can see the > potential to actually want to change the APIC ID - in particular, if the > SMP MP tables say that the APIC ID for the BP should be X, maybe we > should actually write X to it instead of just using what is there. That strikes me as the wrong way around. We *are* booting on this CPU, so the MPS tables are wrong. Why reprogram reality to fit the MPS tables? Also, you don't know what the other CPUs phys ID's really are if everything is inconsistent anyway ... if the MPS tables say boot is phys 0, and phys 1 also exists, and we find we're on phys 1, what now? Also, if we kexec from a non-original boot cpu, we come back with that CPU as the boot CPU, which is correct, but doesn't match the MPS tables .. the one liner I sent before will fix that. Wouldn't it be better to just leave the phys apicids as is, and just print a warning of the MPS tables boot flags don't match up with reality? Seems far less drastic to me. > In particular, Mikaels patch will BUG() if the MP tables don't match the > APIC ID. I think that's extremely rude: we should select one of the two > and just run with it, instead of unconditionally failing. OK, that's bad. SMP does that currently too, but it's easy to fix without going to the extent of reprogramming things that we don't really understand the state of (because we have inconsistent info) 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/