From owner-freebsd-arch@FreeBSD.ORG Mon Nov 20 18:43:18 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 DB71316A519 for ; Mon, 20 Nov 2006 18:43:18 +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 0765143DBD for ; Mon, 20 Nov 2006 18:41:05 +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 kAKIf70A077243; Mon, 20 Nov 2006 13:41:09 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-arch@freebsd.org Date: Mon, 20 Nov 2006 12:42:57 -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: <200611201242.58088.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]); Mon, 20 Nov 2006 13:41:10 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2207/Mon Nov 20 10:09:00 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: John Polstra Subject: Re: Where do MSI quirks belong? 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: Mon, 20 Nov 2006 18:43:18 -0000 On Sunday 19 November 2006 23:11, John Polstra wrote: > I have at least one motherboard on which MSI doesn't work. It's a > Tyan S2721-533, also known as Thunder i7501 Pro. (When MSI is enabled > and used, it often hangs the system solid.) It seems like we're going > to need a quirk table to deal with this sort of thing. I have a > couple of questions before I work on it. > > First, I assume that whether MSI works or not is at least partially > a function of the motherboard and maybe the BIOS, as opposed to the > chipset. Is that right? At least on this Tyan board, there seem > to be some nice kenv variables (e.g., smbus.planar.product) already > set that could help me recognize the board. Is that a reasonable > approach? It's going to be a function of the chipset, as something in the chipset (presumably a Host -> PCI bridge) has to listen for writes to 0xfeeXXXXXX and convert them into APIC messages. There are two ways I planned on doing this: 1) Allow PCI-PCI bridges to be blacklisted, and the pcib_alloc_msi[x]() methods would compare the bridge's device id against a blacklist. This can matter if you have virtual PCI-PCI bridges that really a HT -> PCI bridge or the like. 2) Blacklist chipsets in the x86 MD code based on the device ID of the first Host -> PCI bridge at device 0.0.0. I haven't worked on this yet as I haven't had a broken system to test on yet. It would also probably be a good idea to see what chipsets Linux blacklists, though we might not have to blacklist as many (e.g. Linux blacklists the 7502 chipset because of issues with level triggered messages, but since we use edge-trigger it seems to work fine). > Second, is there already a similar quirk table that I could simply > extend to deal with this, or does it make more sense to create a new > one? No. > Third, is there already an "initialize the whole PCI subsystem" > function where I could handle the quirk table, or should I add > a new SYSINIT? See above. -- John Baldwin