From owner-freebsd-alpha@FreeBSD.ORG Tue Jun 22 19:01:06 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 7224216A4CE for ; Tue, 22 Jun 2004 19:01:06 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F16543D49 for ; Tue, 22 Jun 2004 19:01:05 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i5MJ10aI047896 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Tue, 22 Jun 2004 21:01:02 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i5MJ0UUi041556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Jun 2004 21:00:31 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id i5MJ0UWI023371; Tue, 22 Jun 2004 21:00:30 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id i5MJ0TVQ023370; Tue, 22 Jun 2004 21:00:29 +0200 (CEST) (envelope-from ticso) Date: Tue, 22 Jun 2004 21:00:29 +0200 From: Bernd Walter To: Michael Kukat Message-ID: <20040622190028.GB21460@cicely12.cicely.de> References: <20040622200019.M3751@calchas.unixiron.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040622200019.M3751@calchas.unixiron.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on cicely12.cicely.de 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 Reply-To: ticso@cicely.de 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:01:06 -0000 On Tue, Jun 22, 2004 at 08:15:04PM +0200, Michael Kukat wrote: > Hello, > > okay, the problem is old i think. I just want to know if someone has a solution > for this :) > > Situation: Since a while, my new server runs on FreeBSD/alpha. It's a PC164 > with 512 Megs of RAM and 557 GB of storage (3ware Escalade IDE-RAID). > Everything is fine. But some days ago, i put an Adaptec ANA-62044 in this box, > built a kernel with sf driver, booted, saw a machine check. After analyzing the > situation a bit, and googling a lot, i found out, I/O ports of the 4 NIC chips > are mostly configured for 0x0-0xff. Quite useless values i think. Memory areas > are configured correctly, and the IRQs also look okay: I don't know any alpha system that configure port range behind bridges. Drivers and hardware that agree with PCI specs really shouldn't require port ranges to exist - well unfortunately that's hard to do in real world. 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. > The bus bridge: > pcib1: at device 7.0 on pci0 > pci1: on pcib1 > > The NIC chips: > sf0: port 0-0xff mem 0x82980000-0x829fffff irq 1 at device 4.0 on pci1 > sf1: port 0-0xff mem 0x82900000-0x8297ffff irq 8 at device 5.0 on pci1 > sf2: port 0-0xff mem 0x82880000-0x828fffff irq 12 at device 6.0 on pci1 > sf3: port 0x10000-0x100ff mem 0x82800000-0x8287ffff irq 16 at device 7.0 on pci1 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, the last one seems to have a more useful I/O port. This output was > possible by using #undef SF_USEIOSPACE in if_sf.c. Without, sf0 - sf2 are > skipped with bogus MAC address and "reset never completed". The machine check > occurs after the sf3 probing (which is named sf0 then, as the others failed). 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. Port range on alpha is just a separate range of memory mapped anyway. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de