From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261813AbUJYOJO (ORCPT ); Mon, 25 Oct 2004 10:09:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261817AbUJYOJO (ORCPT ); Mon, 25 Oct 2004 10:09:14 -0400 Received: from aun.it.uu.se ([130.238.12.36]:16256 "EHLO aun.it.uu.se") by vger.kernel.org with ESMTP id S261813AbUJYOJK (ORCPT ); Mon, 25 Oct 2004 10:09:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16765.2298.953135.524930@alkaid.it.uu.se> Date: Mon, 25 Oct 2004 16:08:58 +0200 From: Mikael Pettersson To: "Maciej W. Rozycki" Cc: Alan Cox , "mobil@wodkahexe.de" , linux-kernel@vger.kernel.org Subject: Re: 2.6.9-rc4 No local APIC present or hardware disabled In-Reply-To: References: <20041012195448.2eaabcea.mobil@wodkahexe.de> <16750.23132.41441.649851@alkaid.it.uu.se> <16751.54873.668167.981073@alkaid.it.uu.se> X-Mailer: VM 7.17 under Emacs 20.7.1 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Maciej W. Rozycki writes: > > I agree with Alan that accusing the BIOS of being buggy is unwarranted. > > I disagree. If the firmware performs any actions on hardware without > asking the OS for permission, it *must* be prepared for it to be in any > possible state and handle it correctly, including any transitional states > (as it does respect spinlocks). Otherwise it's buggy. But in this case the BIOS explicitly disabled the local APIC. It may have a legitimate reason for doing so (e.g. old #SMM code), so if the Linux kernel overrides that disablement and things break, it really is the kernel's fault not the BIOS'. > patch-2.6.9-lapic-7 I'm Ok with this patch. /Mikael