From owner-freebsd-arch@FreeBSD.ORG Tue Dec 12 20:22:01 2006 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC89716A64E for ; Tue, 12 Dec 2006 20:22:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 326B344383 for ; Tue, 12 Dec 2006 20:07:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id kBCK8rBA021195; Tue, 12 Dec 2006 15:08:54 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: John Polstra Date: Tue, 12 Dec 2006 15:09:03 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612121509.03785.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 12 Dec 2006 15:08:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2318/Tue Dec 12 11:58:25 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-arch@freebsd.org Subject: Re: Where do MSI quirks belong? [patch] 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: Tue, 12 Dec 2006 20:22:02 -0000 On Monday 11 December 2006 18:23, John Polstra wrote: > On 11-Dec-2006 John Baldwin wrote: > > Hmm. I did blacklist stuff several weeks ago but haven't had time to > > test it or post it yet. :( > > Oops. :-} Hardly your fault though. :) > > I do think I like your approach a bit better though. What I had so > > far is here: > > > > http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch > > > > I'm not sure if it's worth blacklisting MSI separate from MSI-X as that > > only makes a difference at the device level (chipsets just get a single > > memory write per interrupt either way, they can't tell MSI from MSI-X). > > Since the MSI support is really your turf, I'll happily defer to > you on it. If you decide my patch should go in, I could add the > additional blacklisted bridges from your patch, add the tunable > to ignore the blacklist, and eliminate the distinction between > blacklisting MSI and MSI-X. Let me know whether I should go ahead > and commit that. Well, I've tried to update my tree to be similar to your patch. One thing I did keep is that I want the blacklisting of PCI-PCI bridges to be something that happens while the request is bubbling up rather than just do a check on the immediate parent as in your patch. I want to make sure the entire heirarchy beneath a known busted bridge is blacklisted, not just the immediate children. I've gone ahead and committed some of the framework (such as giving the host drivers their own alloc methods) but I've changed the global blacklist to be MI as in your patch. Rather than creating a separate quirk table for MSI, I just added a new quirk type to the pci_quirks[] table and added the quirks there. Updated patch (relative to the stuff I just committed) is at the same location: http://www.FreeBSD.org/~jhb/patches/msi_blacklist.patch Can you review and possibly test it? -- John Baldwin