From owner-freebsd-current@FreeBSD.ORG Mon Apr 11 15:59:49 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5EFB916A4CE for ; Mon, 11 Apr 2005 15:59:49 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83BFE43D4C for ; Mon, 11 Apr 2005 15:59:46 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j3BG386U031568; Mon, 11 Apr 2005 10:03:08 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <425A9E30.7080401@samsco.org> Date: Mon, 11 Apr 2005 09:56:32 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <20050406233405.O47071@carver.gumbysoft.com> <200504081656.51917.jhb@FreeBSD.org> <20050410152946.W82708@carver.gumbysoft.com> <20050410172818.D82708@carver.gumbysoft.com> <200504110231.j3B2VOYr047361@apollo.backplane.com> <425A10DD.70500@samsco.org> <16986.39851.597421.478406@grasshopper.cs.duke.edu> In-Reply-To: <16986.39851.597421.478406@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: Potential source of interrupt aliasing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2005 15:59:49 -0000 Andrew Gallatin wrote: > Scott Long writes: > > > > See also: sbus(4), msi(4). > > > > MSI is something that I'd like to work on, but simply had the time. > > It's not a panacea since it will only work for MSI-enabled PCI devices, > > but many peripherals found on these Intel systems fall into that > > category. > > Bear in mind that MSI is another can of worms. > > I spent some time last month getting MSI interrupts working for our > linux driver. I had the misfortune to start with a system > (ServerWorks GC-SL based) which did not even support MSIs, but where > linux let my driver enable MSI operation and allocate MSI interrupts. > Any DMA to the address given by the linux MSI code resulted in a PCI > master abort. That was not fun.. > > If/when we do MSI support, I really hope we do a better job of determining > if MSIs actually work before enabling them ;) > > Drew > > > I'm a little confused by this. Between the Intel architecture manuals and the PCI specs, it seems like MSI is a function of the PCI device mastering a 32 or 64-bit word into a specific location in host memory. On the intel architecture, that location is in an area that the L-APICs will sniff and treat as a kind of virtual IOAPIC. Maybe you're not actually hitting real RAM and instead there is Host Bridge magic going on, but the Intel manuals don't really talk at all about that. The Linux MSI support was written by Intel so I'm sure they tailored it for Intel chipsets and didn't care much about ServerWorks chipsets. Maybe this is yet another reason why we need to start seriously thinking about chipset drivers in FreeBSD. Scott