Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755723AbZAME1X (ORCPT ); Mon, 12 Jan 2009 23:27:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751762AbZAME1K (ORCPT ); Mon, 12 Jan 2009 23:27:10 -0500 Received: from mx2.redhat.com ([66.187.237.31]:53188 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751409AbZAME1J (ORCPT ); Mon, 12 Jan 2009 23:27:09 -0500 Subject: Re: PCI, ACPI, IRQ, IOAPIC: reroute PCI interrupt to legacy boot interrupt equivalent From: Jon Masters To: "Eric W. Biederman" Cc: Ingo Molnar , Bjorn Helgaas , Stefan Assmann , Len Brown , Jesse Barnes , Olaf Dabrunz , Thomas Gleixner , Steven Rostedt , Linux Kernel Mailing List , linux-acpi@vger.kernel.org, Sven Dietrich , "Maciej W. Rozycki" In-Reply-To: References: <496B24E5.1070804@suse.de> <200901121151.53195.bjorn.helgaas@hp.com> <1231806563.4094.25.camel@perihelion.bos.jonmasters.org> <20090113014723.GA11366@elte.hu> Content-Type: text/plain Organization: Red Hat, Inc. Date: Mon, 12 Jan 2009 23:26:38 -0500 Message-Id: <1231820798.4094.34.camel@perihelion.bos.jonmasters.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1525 Lines: 33 On Mon, 2009-01-12 at 19:47 -0800, Eric W. Biederman wrote: > Ingo Molnar writes: > > a number of mainline drivers also mask/unmask irqs from within the IRQ > > handler. It's not particularly smart in a native driver, but can happen - > > and if we get an active line after that point (and this can happen because > > the driver is active), we are in trouble. > > Yep. Right now it might be simpler to fix the mainline drivers. Taking the easy option now doesn't make the pain go away later :) Just because ACPI doesn't provide a handy description doesn't mean we shouldn't handle "boot interrupts" - the kernel is riddled with quirks already to deal with broken, buggy, or just quirky hardware scenarios. > We are outside the descriptions provided by ACPI so it requires > chipset specific knowledge, and a general understanding of how > chipsets work to actually even comprehend the problem. But how does that differ from most other chipset code? I'm not being belligerent but I'm not seeing how your argument is uniquely special to this particular situation. Personally, I'm a little biased because I'd eventually like to see RT merged upstream and I /know/ that's going to re-open this whole can of worms once again, even if it's "fixed" now. Jon. -- 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/