Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754227AbYCCObQ (ORCPT ); Mon, 3 Mar 2008 09:31:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751847AbYCCObE (ORCPT ); Mon, 3 Mar 2008 09:31:04 -0500 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.123]:54045 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751921AbYCCObD (ORCPT ); Mon, 3 Mar 2008 09:31:03 -0500 Date: Mon, 3 Mar 2008 09:31:00 -0500 (EST) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Mark Hounschell cc: Jon Masters , Mark Hounschell , linux-kernel , Ingo Molnar , Thomas Gleixner Subject: Re: 2.6.24-rt1 IRQ routing anomaly In-Reply-To: <47CBFED1.7090903@compro.net> Message-ID: References: <47BD6802.60604@cfl.rr.com> <47BD7D09.9050106@compro.net> <1204518711.22885.68.camel@perihelion> <47CBFED1.7090903@compro.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2172 Lines: 51 On Mon, 3 Mar 2008, Mark Hounschell wrote: 5B> > > > > Steve is correct. I have plenty of other choices. Steve, you mentioned, a "work around" > is in -rt3. My only concern is does the current "work around" for other hardware really > work or may I see this again with other "non cheap" hardware? We have a work around for secondary IOAPICS, which sometimes shows this behaviour (on non-cheap hardware). The problem we have is that for some reason, IO-APICS with PCI-X chips get confused when the interrupt line is masked. The work around that we currently have (besides noapic) is to switch the interrupt to an edged level interrupt instead of masking. We mark the interrupt as IN_PROGRESS and if new interrupts come in from the same line, we can just flag them as pending and return. This works for some boxes. But this can cause problems for other boxes that don't like having the interrupt being switched from level to edge and back. For these boxes, the workaround must be disabled. Then we have a third set of boxes where the masking causes wrong interrupts (like what you were seeing) and the level/edge hack also causes problems. For these boxes the only current solution is noapic. The last solution to this, which is also our long term fix, is to add a new interface for devices to let them disable the interrupt at the device level (not masked at the IO-APIC). The disadvantage to this is the longer time to traverse the PCI Bus, and added traffic on it. But the advantage is not only a fix to this problem, but a way to figrane the priorities of interrupts further than just the interrupt line. With this fix we can create an interrupt thread per device. Also making the use of tasklets and softirqs obsolete. But this has a long way to go still. > > Is there a known list of hardware this problem is seen on? We know of some, the list is still growing. Jon, where are we on the "blacklist"? -- Steve -- 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/