From owner-freebsd-alpha@FreeBSD.ORG Tue Jun 22 19:25:56 2004 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E30716A4CE for ; Tue, 22 Jun 2004 19:25:56 +0000 (GMT) Received: from mail.unixiron.org (mail.unixiron.org [62.80.47.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DAEF43D5A for ; Tue, 22 Jun 2004 19:25:55 +0000 (GMT) (envelope-from michael@unixiron.org) Received: from mail.unixiron.org (mail.unixiron.org [62.80.47.42]) by mail.unixiron.org (8.12.11/8.12.11) with ESMTP id i5MJPOEI004229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jun 2004 21:25:25 +0200 (CEST) (envelope-from michael@unixiron.org) Date: Tue, 22 Jun 2004 21:25:24 +0200 (CEST) From: Michael Kukat To: ticso@cicely.de In-Reply-To: <20040622190028.GB21460@cicely12.cicely.de> Message-ID: <20040622211907.Y3751@calchas.unixiron.org> References: <20040622200019.M3751@calchas.unixiron.org> <20040622190028.GB21460@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: clamd / ClamAV version 0.67-1, clamav-milter version 0.67a X-Spam-Status: No, hits=-100.0 required=2.0 tests=USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on calchas.unixiron.org cc: freebsd-alpha@freebsd.org Subject: Re: SRM not initialising cards behind a bridge X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2004 19:25:56 -0000 Hello, On Tue, 22 Jun 2004, Bernd Walter wrote: > Port ranges are very small compared to memory and hard to distribute > over many bridges, because ranges have to be bridged in a single > continuous block and you can't reallocate ranges later without driver > interaction. Yep, i saw some things in Leenox, but if i look into those source, i never feel very well afterwards :) But this makes me understand some of the problems we get here. > Everything is absolutely correct in the sense of PCI specs. > Even the obscure data in the port range registers are OK because the > bridge is configured to have port range bridging disabled. > The bus space allocation will fail so the driver knows that it's > unuseable and should fall back to memory. Okay, maybe some driver problem then. But not a real problem, as there is this nifty #define to work around this. Not really configurable in kernel cfg files, but at least in the source, which is okay for a home setup. > Maybe you have hardware at those addresses, but in fact it can't be > this NIC, because the bridge hasn't connected the port range to this > bus. > You should get the driver using memory ranges. Okay. After reading the comments of if_sf.c this also sounds good for me, as just 256 bytes can be addressed directly, the rest just via index register. So memory mapped I/O should even perform better. I'll leave in the #undef to drive it memory mapped, and try to track down the access problems, if nobody else had problems with StarFire drivers in FreeBSD/alpha. Seems to be a quite rare configuration, but i want to put this card into the alpha, as it's 64bit, and the other machine needing quadport ethernet (i386) just has 32bit slots. "It just looks better this way" :) > Port range on alpha is just a separate range of memory mapped anyway. Thought so. I think there are not much CPUs besides Intel differentiating between I/O and memory ranges this way. Everything else i know does memory mapped I/O. ...Michael -- http://www.unixiron.org/ Home Powered by: (Net|Open|Free)BSD IRIX NonStop-UX Solaris AIX HP-UX Tru64 MUNIX Ultrix VMS SINIX Dolphin_Unix OpenStep MacOS A/UX