Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 14 Jan 2002 09:22:35 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 14 Jan 2002 09:22:25 -0500 Received: from delta.ds2.pg.gda.pl ([213.192.72.1]:59065 "EHLO delta.ds2.pg.gda.pl") by vger.kernel.org with ESMTP id ; Mon, 14 Jan 2002 09:22:13 -0500 Date: Mon, 14 Jan 2002 15:19:00 +0100 (MET) From: "Maciej W. Rozycki" To: Zwane Mwaikambo cc: Jim Studt , Linux Kernel Subject: Re: Problem with ServerWorks CNB20LE and lost interrupts In-Reply-To: Message-ID: Organization: Technical University of Gdansk 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 On Mon, 14 Jan 2002, Zwane Mwaikambo wrote: > You may have noticed the great deal of "hacks" which people have put into > the kernel over the years to get it to work with the imperfect world of > hardware. It makes you wonder wether we should waste our time supporting Well, I added a few trivial firmware workarounds myself, but the question is how much we can obfuscate the kernel before it gets to the point of insanity and how much effort one should put in them before deciding it's not worth the trouble. One-liners are usually fine, but is anything more complex? And I/O APIC routing table bugs are quite hopeless -- you need to know the physical layout of traces on a given PCB before even trying to do anything useful. > broken hardware... Then again if we didn't we'd only run on 0.1% of the > boxes out there ;) But... i'm in no way advocating for adding more > kludges. SMP hardware is mostly targetted to the server market which seems to care of Linux due to many customers running it. If they ask vendors for fixes or choose another brand (surprisingly enough, there are vendors that can get their MP tables right), the vendors will start fixing bugs. If we work them around, they will not, as there won't be a reason to. The "noapic" option should probably get removed -- it was meant as a debugging aid (as many of the "no*" options) at the early days of I/O APIC support, I believe... Now the support is pretty stable. -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available + - 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/