Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 14 Oct 2001 16:33:19 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 14 Oct 2001 16:33:09 -0400 Received: from zero.aec.at ([195.3.98.22]:12550 "HELO zero.aec.at") by vger.kernel.org with SMTP id ; Sun, 14 Oct 2001 16:32:57 -0400 To: "Tommy Faasen" cc: linux-kernel@vger.kernel.org Subject: Re: SMP processor rework help needed In-Reply-To: <000b01c154ee$1d6a2610$6400a8c0@it0> From: Andi Kleen Date: 14 Oct 2001 22:33:27 +0200 In-Reply-To: "Tommy Faasen"'s message of "Sun, 14 Oct 2001 22:23:37 +0200" Message-ID: Lines: 25 User-Agent: Gnus/5.0700000000000003 (Pterodactyl Gnus v0.83) Emacs/20.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org In article <000b01c154ee$1d6a2610$6400a8c0@it0>, "Tommy Faasen" writes: > Hi, > I have this unique situation where cpu 1 has less features (like fxsr) then > cpu 0. I used to have such an AMP machine too: a dual PII-300 with one Katmai and one Deschutes. It's technically a violation of the specs; the Intel SMP spec requires that the non boot cpus need to have a superset of the features of the boot CPU. One CPU died, so it is symmetric now. For most capabilities it should already work in 2.4 after hpa's cpu set rewrite, but FXSAVE is unfortunately a bit of a special case because it is used in the scheduler context switch and that is required early in the initialization for SMP bootup and changing it would be very intrusive. In the 2.2 SuSE kernel it was fixed instead by adding a new kernel command line option nofxsave that overrides the FXSAVE bit on the first CPU. That is ok because such setup is very rare and is only generated by people who build their own boxes; and these should also know how to pass kernel command line arguments. Such an option should also be easy to add to 2.4. -Andi - 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/