From owner-freebsd-arch@FreeBSD.ORG Thu Apr 16 17:39:36 2009 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14A361065687 for ; Thu, 16 Apr 2009 17:39:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7E378FC1F for ; Thu, 16 Apr 2009 17:39:35 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 8C9AA46B35; Thu, 16 Apr 2009 13:39:35 -0400 (EDT) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.8]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 807D08A01C; Thu, 16 Apr 2009 13:39:34 -0400 (EDT) From: John Baldwin To: Marius Strobl Date: Thu, 16 Apr 2009 13:37:38 -0400 User-Agent: KMail/1.9.7 References: <200904151324.06754.jhb@freebsd.org> <200904151737.09769.jhb@freebsd.org> <20090416170331.GA30118@alchemy.franken.de> In-Reply-To: <20090416170331.GA30118@alchemy.franken.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904161337.38593.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Thu, 16 Apr 2009 13:39:34 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=4.2 tests=RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: arch@freebsd.org, Marcel Moolenaar Subject: Re: Enabling interrupt filters by default X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:39:39 -0000 On Thursday 16 April 2009 1:03:31 pm Marius Strobl wrote: > On Wed, Apr 15, 2009 at 05:37:09PM -0400, John Baldwin wrote: > > On Wednesday 15 April 2009 4:36:30 pm Marcel Moolenaar wrote: > > > > > > On Apr 15, 2009, at 1:13 PM, John Baldwin wrote: > > > > > > > On Wednesday 15 April 2009 2:04:14 pm Marcel Moolenaar wrote: > > > >> > > > >> On Apr 15, 2009, at 10:24 AM, John Baldwin wrote: > > > >> > > > >>> A while ago I changed the interrupt code in 8.x such that all the MD > > > >>> code was > > > >>> the same for both the INTR_FILTER and non-INTR_FILTER case. I would > > > >>> like to > > > >>> flip the switch to enable INTR_FILTER by default. Any objections? > > > >> > > > >> Last time it was found to be not working. Did we fix it? > > > > > > > > Err, when was that? > > > > > > August 2007. > > > > I rototilled all the MD interrupt code to make both the filter and !filter MD > > code identical and both sets use the same callout routines (post_filter, > > etc.) in April 2008. > > > > > > I know folks have used it on amd64 and i386 ok and I have > > > > tested it on both of those platforms. One of the arm kernel configs > > > > uses it > > > > by default. > > > > > > There was interrupt starvation on sparc64. There were also > > > issues with permanently masking stray interrupts. This is > > > problematic when interrupts are shared and there is at least > > > 1 filter on it. > > > > > > FYI, > > > > The MD interrupt code has changed quite a bit since then and I explicitly > > worked with marius@ and others to test the aforementioned changes (though > > various platforms may have only tested the !filter case at the time). > > The MI part of INTR_FILTER still doesn't work properly when > multiple filters share one interrupt, resulting in a hang > during device attachment. After reviewing the INTR_FILTER code > back in August 2007 scottl@ wrote a private mail to marcel@ > and me confirming that problem and saying he even found more > and even excusing for having pushed the switch to INTR_FILTER > for 7.0. Given that the INTR_FILTER code in kern_intr.c for the > most part seems unchanged since piso@ committed it probably > means that these problems still exist today. Apart from the > problem when filters share an interrupt, INTR_FILTER looked > good on sparc64 though last time I tested. Ok, I have not heard of this before. I will try to devise some test cases. -- John Baldwin